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FOREWARD 


This  report  on  the  study  of  an  Accreditation  Policy  for  embed¬ 
ded  computers  proposes  a  methodology  for  an  implementation  of  the 
policy*  The  objective  of  the  report  is  to  critically  evaluate  the 
concept  of  accreditation  and  to  specify  a  procurement  philosophy 
that  will  improve  the  Navy's  ability  to  field  militarily  effective 
tactical  systems  at  the  lowest  cost  to  the  Navy.  The  concept  of 
accreditation,  as  set  forth  by  the  Navy,  involves  creating  a  com¬ 
petitive  environment  for  the  procurement  of  embedded  computers  by 
acquiring  multiple  computers  for  various  ranges  of  performance . 

PRC/ISC's  approach  to  the  study  was  to  view  the  goals  of  the 
Navy's  Accreditation  Policy  and  the  related  technological  problems 
from  a  predominantly  management  perspective.  Implicit  in  this 
approach  is  the  belief  that  an  overall  framework  for  addressing 
the  complex  and  interdependent  technological  issues  must  be  defined 
before  the  details  of  each  of  the  technological  issues  can  be  con¬ 
sidered.  Thus,  an  appreciation  for  the  overall  problem  should  be 
gained  before  attention  is  centered  on  distinct  segments  of  the 
problem. 

In  addition,  the  report  asserts  that  an  effective  policy  must 
balance  the  goals  of  all  the  participants — agents  of  the  Navy  and 
vendors.  Only  in  that  way  will  a  relationship  be  established  that 
will  allow  the  Navy  to  take  advantage  of  ongoing  technological 
advances  in  the  computer  industry. 

The  proposed  policy  is  based  on  the  following  premises: 

•  The  Navy  should  fund  parallel,  full-scale  Engineering 
Development  (FSED)  efforts  to  obtain  multiple  accredited 
computers.  An  FSED  effort  would  involve  the  militariza¬ 
tion  of  proven  technology  rather  than  the  development  of 
new  technology  under  an  R&D  program.  Manufacture  of 
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production  units  would  take  place  only  as  a  result  of  a 
Program  Manager's  decision  to  purchase  one  of  the  accred¬ 
ited  computers. 

•  Creation  of  a  competitive  environment  for  the  proposal, 

FSED  and  purchase  activities  is  expected  to  result  in 
reduced  costs  to  the  Navy  and  improved  computer  perform¬ 
ance.  The  resulting  improved  technology  could  be  exploited 
(perhaps  by  revising  approaches  to  operation  and  mainte¬ 
nance  activities)  to  reduce  logistics  and  maintenance  costs. 

The  Navy  would  communicate  its  critical  concerns  to  vendors  to 
provide  guidance  for  design  decisions  instead  of  dictating  explicit 
specifications  for  meeting  all  of  those  concerns. 

The  proposed  policy  makes  two  assumptions: 

•  If  competition  in  the  form  of  multiple  accredited  computers 
can  be  promoted,  then  the  cost  of  the  procured  technology 
will  decline. 

•  The  acquisition  of  improved  technology  will  result  in 
reduced  maintenance  costs. 

While  both  assumptions  are  for  the  most  part  intuitively  accept¬ 
able,  they  will  have  to  be  further  validated  by  a  process  defined 
in  the  report  using  historical  data  and  technology  assessment. 

The  following  topics  are  discussed  in  the  report: 

•  Goals  of  the  policy. 

•  Considerations  in  attracting  multiple  vendors  to  participate 
in  the  policy  and,  thereby,  promoting  competition. 

e  Significance  of  Instruction  Set  Architecture  standardiza¬ 
tion. 
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•  Characteristics  of  and  a  way  to  manage  the  list  of 
accredited  computers. 

•  The  role  of  life  cycle  costs  in  comparing  comparable 
computers . 

•  The  relationship  between  accreditation  and  current  Navy 
acquisition  procedures. 

•  The  impact  of  technology  trends  on  maintenance  costs. 

•  The  responsibilities  of  a  program  manager  in  selecting 
an  accredited  computer  for  use  in  a  tactical  system. 

•  Trade-offs  involved  in  technology  selection. 


SECTION!.  INTRODUCTION 


1.1 


urpose , 


This  report  presents  the  analysis  and  conclusions  of  PRC/ISC’s 
study  of  the  Navy's  proposal  for  a  policy  for  accreditation  for 
embedded  computers.  The  concept  of  accreditation,  as  advanced  by 
the  Navy,  can  be  summarized  as  the  reliance  on  the  availability  of 
competing  computers  in  each  of  various  performance  ranges.  These 
computers  would  then  provide  each  Program  Manager  with  competing 
alternatives  that  could  be  used  in  designing  a  system  with  a  result 
ant  reduction  in  the  total  life  cycle  costs  for  the  system.  The 
Accreditation  Policy  is  viewed  as  an  effort  to  relieve  some  of  the 
problems  currently  experienced  by  the  Navy  in  the  acquisition,  use 
and  support  of  embedded  computers . 


1.2  Statement  of  the  Problem. 


The  deficiencies  and  costliness  of  the  Navy's  shipboard  data 

processing  environment  are  well  known  to  anyone  associated  with  a 
1  2 

shipboard  system  '  .  The  state  of  that  environment  is  discussed  in 

the  Pinal  Report  of  the  Navy  Embedded  Computer  Review  Panel,  Octobe 
3 

1978  .  That  report  notes  several  issues  that  constrain  the  effec¬ 
tiveness  of  the  Navy's  systems: 


•  Standardization  inhibits  the  acquisition  of  new  tech¬ 
nology  (which  provides  improved  capability  and  relia¬ 
bility)  and  limits  competition  among  vendors  for  the 
development  of  Navy  computers. 


•  Many  systems  must  be  operated  and  maintained  at  sea  with 
a  maintenance  and  logistics  support  capability  which  is 
reliant  on  limited  personnel  resources. 


In  addition,  the  Navy  report  notes  that  the  projected  use  of 
embedded  systems  will  increase  while  the  availability  of  trained 
personnel  needed  to  maintain  them  will  decline.  Finally,  it  is 


generally  agreed  that  performance  gains  would  accrue  if  greater 
use  could  be  made  of  the  ever  improving  technology  in  the  commer¬ 
cial  world.  Because  the  Navy's  computer  technology  does  not 
undergo  periodic  upgrade,  operational  requirements  predate  tech¬ 
nology  instead  of  exploiting  extant  state-of-the-art  technology. 
Therefore,  the  system  development  cycle  is  lengthened  by  the  time 
necessary  to  define  and  produce  the  required  technology.  Con¬ 
sequently,  the  technology  is  no  longer  optimal  by  the  time  it  is 
perfected.  Worse  still,  ventures  into  new  technology  and  the 
development  of  needed  tactical  systems  are  often  discouraged  by 
the  cited  technology  lag. 

In  view  of  the  improved  military  effectiveness  that  would  be 
obtained  if  these  problems  were  resolved,  this  report  attempts  to 
proceed  toward  that  goal  by  defining  a  feasible  policy  for  the 
improved  management  of  Navy  computers.  This  policy  will  establish 
a  balance  among  the  needs  of  the  Navy,  practices  of  commercial 
vendors  and  technology  trends . 

1. 3  Scope  of  Accreditation  Policy  Study. 

The  following  considerations  are  addressed  to  assure  a  policy 
that  is  consistent  and  workable  from  a  management  perspective: 

•  The  prospective  business  relationship  between  the  Navy 
and  commercial  vendors. 

•  Practical  acquisition  of  commercial  technology  by  the 
Navy. 

•  Handling  of  the  Navy's  logistics  and  maintenance  require¬ 
ments  within  the  context  of  the  expected  improved  tech¬ 
nology  at  its  disposal. 

This  study  will  define  the  basic  premises  of  a  workable, 
effective  Accreditation  Policy.  The  level  of  detail  provided  is 
intended  to  ensure  that  all  essential  issues  are  addressed,  though 


perhaps  not  resolved  since  additional  data  from  the  Navy  and 
vendors  is  required  to  validate  the  policy  concept.  In  addition, 
no  attempt  was  made  to  tie  the  policy  to  a  specific  scenario  of 
Navy  or  computer  industry  directions  in  the  future.  Instead, 
likely  trends  were  employed  as  guidelines  for  prospective  deci¬ 
sions  or  actions. 

For  the  purposes  of  the  study,  the  phrase  "embedded  computers" 
was  assumed  to  encompass  all  digital  processor-based  devices  which 
are  used  in  tactical  shipboard  systems  as  (1)  aids  to  general  pur¬ 
pose  computing  tasks,  (2)  controllers  providing  real-time  direc¬ 
tion  or  decision  making  for  tactical  systems  and  equipment  and 
(3)  programmed  logic  elements  replacing  the  wired  logic  of  hard¬ 
ware  devices.  Only  the  hardware  domain  of  embedded  computers  was 
addressed  within  the  constraints  stipulated  for  conduct  of  the 
study . 


1.4  Report  Organization 

This  report  is  organized  along  the  lines  of  the  process  by 
which  the  policy  was  derived: 

•  First  the  subject  of  the  study  was  defined.  This  was 
achieved  by  (1)  examining  the  procedures  that  the  Navy 
currently  uses  in  acquiring  and  utilizing  computers  and 
(2)  ascertaining  the  ramifications  of  those  procedures. 

Then  the  Navy's  goals,  as  set  forth  by  the  principle  of 
accreditation,  were  analyzed  to  gain  another  perspective 
on  the  study  topic  and  to  determine  the  policy's  require¬ 
ments  . 

•  Then  ways  of  achieving  the  goals  as  well  as  the  rationale 
for  and  implications  of  those  strategies  were  documented. 
The  process  of  identifying  suitable  strategies  for  achiev¬ 
ing  the  Navy's  goals  involved  (1)  identification  of  funda¬ 
mental  (if  not  axiomatic)  steps  in  the  acquisition  process. 
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(2)  examination  of  the  factors  associated  with  each  of 
the  acquisition  steps,  (3)  consideration  of  alternative 
ways  of  performing  each  of  the  steps,  and  (4)  specifica¬ 
tion  of  the  preferred  treatment  of  those  activities  with 
supporting  arguments  that,  by  implication,  dismiss  the 
alternative  treatments. 

•  Finally,  a  chronology  of  activities  necessary  to  imple¬ 
ment  the  Accreditation  Program  was  stated.  The  required 
actions  ranged  from  preparations  for  executing  the  accred¬ 
itation  process  to  the  actual  acquisition  procedures  that 
would  be  performed  to  obtain  and  use  an  accredited  com¬ 
puter. 


P 


SECTION  2.  BACKGROUND 


The  procedural  issues  involved  in  the  acquisition  of  a  new 
computer  for  Navy  use  under  current  policies  are  documented  and 
analyzed  in  this  section.  Emphasis  is  placed  on  the  development 
(implementation)  and  operational  use  of  a  computer.  The  purpose 
of  the  following  discussion  is  to  identify  issues  that  are  per¬ 
tinent  to  the  Accreditation  Policy;  for  more  detail  see  SECNAVINST 
4 

5000.1  and  the  documents  cited  in  its  enclosure  3. 

2.1  Hardware  Implementation. 

The  processes  involved  in  the  development  of  a  computer  for 
the  Navy  are  specified  below. 

2.1.1  Requirements  Specifications. 

The  requirements  of  the  computer  are  ascertained  and  docu¬ 
mented.  This  involves  specifying  the  attributes  and  performance 
requirements  of  the  equipment  in  the  context  and  environment  of 
its  expected  use. 

2.1.2  Selection  of  Contractor/Manufacturer. 

A  contractor/manufacturer  for  the  computer  is  selected. 

The  details  of  this  process  will  vary  depending  on  whether  the 
selection  is  sole  source  or  by  competitive  procurement. 

2.1.3  Detailed  Design. 

Based  on  the  computer's  requirements  specification,  a 
detailed  design  is  developed  and  documented;  the  wired  and  micro¬ 
programmed  logic  is  specified.  In  addition,  the  operations  meth¬ 
odology  for  the  equipment  is  established.  Also,  a  maintenance 
plan  for  the  operational  use  of  the  equipment  is  promulgated. 
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2.1.4  Construction. 


Initial  units,  probably  prototypes  for  testing,  are  con¬ 
structed. 

2.1.5  Design  Verification. 

The  initial  units  are  tested  to  verify  that  the  basic 
design  has  been  achieved. 

2.1.6  Production, 

Once  the  design,  with  any  necessary  modifications,  has 
been  verified,  the  production  of  additional  units  can  begin. 

The  production  units  are  quality-checked  and  tested  to  confirm 
that  all  standards  (reliability,  performance,  etc.)  have  been  met. 

2.1.7  Establishment  of  Spares  Inventory. 

Spare  parts  are  produced,  stockpiled  and  inventoried  in 
accordance  with  the  logistics  and  management  concept  to  support 
maintenance  of  the  computers.  Interfaces  with  the  Navy  logistics 
program  are  established. 

2.1.8  Set  Dp  Repair  Depot. 

A  repair  depot  is  set  up  (possibly  as  an  offshoot  of  the 
production  facility)  to  support  depot  or  field  repairs ,  trouble¬ 
shooting,  etc.,  once  the  computer  is  in  operational  use. 

2.1.9  Training . 

Appropriate  Navy  grades  are  trained  in  the  operation  and 
maintenance  of  the  system. 

2.1.10  Availability  for  Shipboard  Installation. 

The  equipment  is  declared  available  for  projected  shipboard 
installation  dates. 


2.1.11  Shipboard  Installation, 

The  computer  is  installed  aboard  ship  during  shipyard 
periods  or  while  at-sea  by  either  contractor,  shipyard  or  ship's 
force  personnel. 

2.2  Requirements  Associated  with  Hardware  Implementation. 

All  of  the  above  steps  have  intrinsic  requirements  for  time 
and  costs  for  necessary  resources  (personnel,  equipment,  facili¬ 
ties,  etc.)  for  both  the  contractor  and  the  Navy. 

The  steps  from  requirements  specification  through  production 
have  special  cost  requirements  due  to  Navy  procurement  practices 
and  standards . 

Training  requirements  involve  the  problem  of  having  capable 
personnel  available  for  training  in  light  of  manpower  levels  in 
the  Navy.  The  degree  of  difficulty  experienced  in  training 
increases  as  the  number  and  complexity  of  computers  increases. 

The  installation-related  issues  stem  from  the  relative 
unavailability  of  the  platform.  The  equipment  must  be  specified 
far  in  advance  of  actual  installation  to  accommodate  the  long  lead 
time  (three  to  five  years)  inherent  in  the  fleet  construction  and 
overhaul  cycles .  Feasible  installation  times  tend  to  be  inter¬ 
mittent,  infrequent  and  highly  competitive  due  to  the  scope  of 
Shipalt  requirements.  This  problem  is  finding  some  relief  as  the 
size  of  computers  and  the  complexity  of  the  installation  are  reduced. 

2 . 3  Impact  of  Standardized  Computer  Policies  on  Hardware 

Implemen tation . 

From  the  standpoints  of  time,  cost  and  procedures,  the 
principal  implementation  steps  are  in  effect  eliminated  for  sub¬ 
sequent  uses  of  a  standard  computer.  There  are,  however. 
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drawbacks  that  have  an  impact  that  can  be  assessed  only  quali¬ 
tatively:  (1)  cost  benefits  that  may  be  gained  from  competitive 

procurements  are  not  realized  and  (2)  computer  design  and  per¬ 
formance  will  tend  to  stagnate  in  the  absence  of  an  infusion  of 
new  ideas  and  technology  coming  from  both  competition  and  new 
technology  post-dating  the  original  specifications. 

The  likelihood  that  equipment  will  be  available  for  ship¬ 
board  installations  is  enhanced;  the  only  prerequisite  is  adequate 
production  rather  than  the  entire  implementation  process. 

2.4  Operation  and  Maintenance. 

Aspects  of  the  operation  and  maintenance  of  an  approved 
Navy  computer  are  specified  below. 

2.4.1  Operation. 

After  being  installed,  the  computer  is  operated  as  part 
of  a  system  to  satisfy  an  operational  requirement. 

2.4.2  Maintenance . 

Activities  associated  with  the  maintenance  of  Navy  com¬ 
puters  are  specified  in  the  following  sections. 

2. 4. 2.1  Preventive  Maintenance. 

Operator  or  maintenance  personnel  perform  periodic 
Planned  Maintenance  (PM)  to  identify  problems  before  they  become 
critical  and  to  maintain  the  equipment  i'.  proper  calibration  and 
alignment . 


2.4. 2. 2  Problem  Identification. 

In  the  course  of  operation,  the  computer  experiences 
problems  related  to  either  design  flaws  or  component  failures. 
Diagnostic  activities  by  the  user,  operator  or  maintenance 


personnel  are  required  to  pinpoint  the  problem.  The  trouble¬ 
shooting  may  rely  on  diagnostic  equipment  or  the  system  itself 
may  aid  in  the  diagnosis  by  actually  reporting  the  problem. 

2. 4. 2. 3  Corrective  Maintenance. 

Identified  problems  are  corrected  by  maintenance  per¬ 
sonnel.  This  can  involve  either  parts  replacement  (using  the 
spares  inventory)  or  actual  repair  of  the  inoperative  or  mal¬ 
functioning  part.  The  repairs  may  be  performed  on  the  organiza¬ 
tional,  intermediate  or  depot  levels. 

2. 4. 2. 4  Spares  Pipeline. 

Spares  used  to  replace  parts  that  fail  must  be  replen¬ 
ished  by  means  of  a  timely  and  effective  spares  supply  pipeline. 

2.4.2. 5  Training  Pipeline. 

Because  maintenance  or  operator  personnel  will  be  rotated 
out  of  a  billet  accommodating  the  computer,  there  is  an  ongoing 
requirement  for  adequately  trained  replacements. 

2. 4. 2. 6  Field  Changes. 

Changes  to  the  equipment  may  be  necessary  after  installa¬ 
tion  to  provide  either  design  corrections  or  enhancements.  These 
changes  may  be  manufacturer-initiated  although  they  may  result 
from  requests  from  the  Navy. 

2.5  Requirements  Associated  with  System  Usage. 

Initial  operation  of  a  system  is  often  in  a  situation  where 
both  the  computer  and  its  software  are  undergoing  their  first 
operational  test.  This  can  complicate  independent  evaluation  of 
the  elements  of  the  system. 


Planned  Maintenance  (PM)  requires  that  properly  trained 
personnel  have  appropriately  scheduled  access  to  the  system. 

Problem  identification  and  correction  can  require  widely 
varying  skill  levels  and  time  depending  on  the  character  of  the 
computer  and  the  effectiveness  of  the  available  diagnostic  tools. 
In  general,  these  maintenance  processes  entail  a  fairly  sophis¬ 
ticated  effort  requiring  a  good  deal  of  training  and  experience. 
The  amount  of  down  time  that  can  be  tolerated  will  vary  depend¬ 
ing  on  the  criticality  of  the  computer  and  the  degree  to  which 
redundancy  is  employed.  Although  highly  reliable  systems  can 
reduce  the  frequency  with  which  these  tasks  must  be  performed,  the 
capability  must  still  be  in  place. 

Utilization  of  spares  requires  that  inventory  be  properly 
monitored  to  facilitate  timely  ordering  and  delivery  to  accom¬ 
modate  the  general  inaccessibility  of  the  ship  to  straightforward 
supply  channels. 

2.6  Impact  of  Standardized  Computer  Policies  on  System  Usage. 

The  primary  impact  of  standardization  is  in  the  area  of 
maintenance  for  subsequent  installations  of  a  standard  computer. 
Whereas  PM  requirements  should  tend  to  remain  the  same,  few 
design  flaws  will  be  found  after  initial  shakedown  testing. 

(This  does  not  necessarily  mean  that  the  skills  required  to 
handle  design  flaws  are  no  longer  needed.)  Problem  identifica¬ 
tion  and  correction  may  be  facilitated  if  related  experience  is 
documented  for  general  dissemination. 

The  Navy's  ability  to  maintain  the  spares  pipeline  is  made 
simpler  due  to  the  economies  of  scale  experienced  with  a  small 
set  of  standardized  computers.  In  addition,  having  a  pool  of 
maintenance  personnel  trained  in  a  limited  set  of  computers  pro¬ 
vides  for  greater  flexibility  in  the  use  of  the  personnel  thereby 
simplifying  staffing. 
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The  need  for  field  changes  related  to  design  corrections 
will  tend  to  diminish  as  reductions  in  the  number  of  design  flaws 
are  found.  However,  the  number  of  enhancement  changes  will  most 
likely  increase  with  more  numerous  and  varied  uses  of  the  computer. 
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SECTION  3.  POLICY  FOUNDATION 


The  essential  elements  of  the  Accreditation  Policy  will  be 
established  in  this  section.  They  will  be  based  on  an  analysis 
of  the  factors  and  issues  involved  in  achieving  the  Navy's 
goals. 

3.1  Policy  Goals. 

In  general  terms,  the  Accreditation  Policy  must  provide 
an  effective  response  to  the  Navy's  overall  requirement  to 
develop  militarily  effective  systems  within  total  cost  and 
budgetary  constraints.  Therefore,  the  policy  must  reduce 
direct  and  indirect  costs  in  light  of  the  inherent  trade-offs 
and  constraints  related  to  technological,  procedural  and  real  world 
issues.  Thus,  the  fundamental  goals  of  the  policy  include: 

•  Increasing  cost,  design  and  performance  competition. 

•  Providing  ongoing  access  to  newer  technology  for 
improved  performance. 

e  Obtaining  computers  that  will  allow  for  the  development 
of  an  improved  maintenance  plan  to  reduce  the  cost  of 
shipboard  maintenance. 

•  Ensuring  that  existing  and  future  standard  Instruction 
Set  Architectures  (ISAs)  will  be  supported  (pre¬ 
sumably  through  emulation) . 

3.2  Factors  Associated  with  the  Accreditation  Policy. 

Obviously,  the  goals  stated  above  are  complex,  interde¬ 
pendent  and  even  contradictory.  Therefore,  any  effective  treat¬ 
ment  of  the  issues  associated  with  the  goals  must  be  comprehensive. 
To  that  end,  the  goals  will  be  viewed  as  objectives  that  must  be 
met  by  strategies  that  take  into  account  the  objectives  them¬ 
selves  as  well  as  all  factors  which  derive  from  the  objectives. 


While  the  stated  strategies  are  based  mostly  on  subjective  judg¬ 
ments,  technological  realities  and  trends  are  also  given  con¬ 
sideration. 

To  provide  a  starting  point  for  the  treatment  of  the 
objectives  and  to  ensure  that  solutions  for  the  diverse  require¬ 
ments  are  logically  consistent,  the  following  basic  premises 
will  be  assumed: 

•  Computers  to  be  used  in  shipboard  systems  will  be 
selected  from  a  list  of  accredited  computers.  The 
accreditation  criteria  will  encompass  various 
engineering  and  performance  parameters.  The  list 
will  be  partitioned  into  multiple  Performance  Ranges 
(PRs) ,  each  defining  a  bounded  range  of  computational 
performance.  Each  PR  will  ideally  contain  more  than 
one  computer.  Because  computational  performance  (as 
a  function  of  such  parameters  as  instruction  execu¬ 
tion  time  and  data  transfer  rates)  is  more  often  than 
not  the  initial  criteria  for  computer  selection,  PRs 
will  serve  as  the  basic  reference  frame  for  the  group¬ 
ing  and  classification  of  accredited  computers. 

•  Capabilities  of  commercial  computers  and  vendors  will 
be  exploited  (with  any  needed  modifications)  to 
satisfy  Navy  requirements.  Proposals  for  develop¬ 
ment  of  computers  for  accreditation  will  be  sought 
from  multiple  vendors  to  create  a  competitive 
environment . 

•  Development  of  accredited  computers  for  use  in  the 
Navy  environment  will  not  involve  R&D  for  new  logic 
technology,  but  rather  will  involve  the  packaging 
(or  militarization)  of  proven  technology. 


•  The  level  of  standardization  in  computers  will  be  on 
the  Instruction  Set  Architecture  (ISA) .  ISA  is  the 
representation  of  a  computer  employed  by  a  programmer 
for  (a)  the  manipulation  of  data,  (b)  the  movement 

of  data  among  registers,  memory  and  the  external 
world  (I/O  devices,  etc.)  and  (c)  the  management  of 
programming  logic  flow. 

•  Management  of  the  Accreditation  Program,  including 
development  of  the  Accreditation  Policy,  will  be  the 
responsibility  of  the  Policy  Administrator.  The 
Policy  Administrator,  in  effect,  acts  as  the  liaison 
between  vendors,  who  develop  embedded  computers,  and 
program  managers  who  use  them  in  shipboard  systems. 

•  The  accreditation  process  will  entail  (a)  environ¬ 
mental  stress  testing  to  determine  if  applicable 
standards  have  been  met,  (b)  benchmark  testing  to 
confirm  the  satisfaction  of  design  constraints  (e.g., 
execution  of  the  standard  ISA  and  adherence  to  inter¬ 
face  requirements)  and  (c)  computation  and  evaluation 
of  the  computer's  life  cycle  costs  from  Full  Scale 
Engineering  Development  (FSED)  through  Operation  and 
Maintenance  (O&M) . 

•  Several  approaches  to  maintenance  problems  will  be 
promulgated  including  the  use  of  system  diagnostics, 
appropriate  maintenance  tasking  and  improved  hard¬ 
ware  design. 

•  Alterations  to  or  reorganization  of  procurement  pro¬ 
cedures  and  practices  will  be  pursued  as  a  way  to 
make  computers  more  readily  available  at  lower  cost. 

Figure  1  provides  a  concise  listing  of  strategies  for  the 
Accreditation  Policy.  In  the  chart,  the  basic  goals  are  noted 
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as  primary  requirements.  From  those  requirements,  solutions 
derived  from  the  above  stated  basic  premises  are  noted.  It 
can  be  seen  that  some  of  the  basic  premises  play  a  part  in  the 
treatment  of  more  than  one  of  the  requirements.  The  issues 
stated  in  Figure  1  are  treated  in  greater  detail  in  the  follow¬ 
ing  sections. 

3.2.1  Elaboration  of  Factors  Associated  With  Policy  Goals. 

In  this  section,  the  requirements  and  solutions  of  the 
policy  are  analyzed  in  greater  detail.  The  analysis  follows 
the  tree  structure  of  Figure  1  in  a  left  to  right  transversal 
from  each  mode  (preorder  traversal) . 

The  examination  of  the  proposed  approach  will  be  based 
on  a  justification  of  each  action  rather  than  a  comparison  of 
alternative  approaches  for  the  entire  policy. 

3 . 2 . 1 . 1  Price  and  Performance  Competition. 

The  primary  goal  of  the  Navy's  Accreditation  Policy 
is  to  gain  price  and  performance  improvements  for  its  e:.ibedded 
computers  by  partaking  more  extensively  of  the  technology 
offered  by  commercial  vendors.  Benefits  should  accrue  both 
from  competition  among  vendors  vying  for  the  Navy  market  as 
well  as  from  continuing  decreases  in  the  cost  of  the  state-of- 
the-art  technology  of  vendors.  Neither  of  these  factors,  which 
can  lead  to  reduced  costs,  are  directly  under  the  control  of 
the  Navy.  In  fact,  the  technology  related  price  decreases  may 
be  small  if  the  cost  to  upgrade  commercial  technology  to  MIL- 
STDS  continues  to  be  a  major  portion  of  militarized  computer 
costs.  Thus,  the  Accreditation  Policy  must  promote  competition 
as  an  indirect  means  to  the  desired  end,  while  also  reducing 
the  costs  upon  which  the  Navy  has  a  direct  influence  (i.e. , 
procurement  policies) . 
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Although  it  is  valid  to  assume  that  competition  will 
have  the  desired  effect  on  cost,  it  cannot  be  assumed  that  com¬ 
petition  will  materialize  without  some  encouragement.  Vendors 
must  be  attracted;  the  Navy  must  make  it  both  procedurally 
easier  and  less  expensive  than  heretofore  for  all  parties  to 
be  involved  in  Navy  business.  Thus,  an  approach  to  Navy-vendor 
interaction  must  be  established  that  will  balance  the  goals 
and  requirements  of  all  involved.  Characteristics  of  the  Navy- 
vendor  interface  that  should  attract  vendors  to  participate  in 
the  program  are  discussed  in  greater  detail  in  the  following 
subsections. 

3. 2. 1.1.1  Level  of  Standardization  in  Embedded  Computers. 

Current  standardization  for  the  entire  computer 
reduces  some  logistics  related  costs,  but  impedes  price  and 
performance  competition.  The  level  of  standardization  that  is 
employed  in  Navy  computers  in  conjunction  with  the  Accreditation 
Policy  will  have  a  significant  influence  on  the  degree  to  which 
vendors  can  interact.  The  level  of  standardization  must  relate 
positively  to  the  way  that  vendors  expect  to  do  business  and 
the  size  and  character  of  the  market  in  which  they  will 
participate.  Therefore,  the  standardization  level  must  be 
optimal  regarding  its  technology,  its  ability  to  satisfy  Navy 
requirements  and  its  compatibility  with  the  directions  of  the 
vendors,  including  the  structuring  of  their  product  line.  The 
ISA  standardization  decided  upon  by  the  Navy  meets  these 
qualifications  and  as  well: 

•  Allows  for  injection  of  new  technology  on  the 
most  dynamic  levels  (processor  logic  and 
architecture)  while  giving  the  vendor  the 
flexibility  to  achieve  an  overall  optimum 
design. 
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•  Allows  a  vendor  to  design  and  build  a  complete 
computer  rather  than  individual  or  isolated 
components,  thereby,  providing  a  reasonable 
product  base. 

•  Provides  a  level  of  standardization  that  should 
reduce  software  development  costs  and  risks  by 
creating  a  well  defined  baseline. 

•  Establishes  a  single  point  for  vendor  interface 
instead  of  multiple  interfaces  that  would  result 
from  card  level  standardization. 

•  Allows  the  Navy  to  perform  a  functional  level 
review  of  computer  design  rather  than  more 
detailed  reviews  that  would  be  required  if  card 
level  standardization  were  employed. 

Standardization  on  an  ISA  does  not  encourage  utili¬ 
zation  of  Plug  Compatible  Modules  (PCMs)  as  much  as  card  level 
standardization.  It  might,  however,  be  feasible  to  exploit 
PCMs  when  either  upgrades  are  not  available  from  the  originat¬ 
ing  vendor  or  the  originating  vendor  is  amenable. 

Accredited  embedded  computers  will  be  required  to 
execute  the  standard  ISA  either  directly  (as  the  native  ISA 
of  the  computer)  or  via  emulation.  The  feasibility  of  emula¬ 
tion  allows  the  Navy  to  require  support  for  multiple  ISAs 
e.g.,  UYK-7,  UYK-20  and  a  new  "universal"  ISA.  Emulation  also 
improves  the  chances  that  vendors  with  commercially  oriented 
microprogrammed  native  ISAs  for  their  computers  will  still  be 
able  to  implement  Navy  ISAs  on  the  same  computer. 

ISA  standardization  is  justifiable  since  it  provides 
upward  compatibility  during  the  transition  from  the  current 
standard  computer  philosophy  to  the  accreditation  philosophy. 

However,  a  change  to  High  Order  Language  (HOL)  standardization  in  the 
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future  will  be  compatible  with  DODI  5000.1  and  required  to 
absorb  advances  in  technology  that  will  inevitably  necessitate 
a  break  with  current  architectures.  Also,  HOL  standardization 
will  eliminate  compliance  with  an  ISA  as  a  factor  that  might 
discourage  vendor  participation  in  the  policy.  As  the  "hard¬ 
ware"  cost  of  supporting  ISAs  approaches  or  exceeds  the  cost 
of  redoing  any  remaining  systems  implemented  in  machine 
dependent  ISAs,  standardization  on  HOL  should  be  undertaken. 

3 . 2 . 1 . 1 . 2  Methodology  for  the  List  of  Accredited  Computers. 

The  principal  management  mechanism  for  embedded 
computers  approved  for  shipboard  use  will  be  the  list  of 
accredited  computers.  The  list  will  identify  the  computers 
that,  by  virtue  of  their  adherence  to  Navy  specifications  and 
standards  for  operation  and  performance,  are  available  for  use 
by  Program  Managers. 

The  concept  of  a  list  of  accredited  computers  must 
take  several  factors  into  consideration.  First,  the  listed 
computers  will,  in  general,  be  viewed  and  treated  as  entities 
unto  themselves  rather  than  as  complete  systems.  Second,  the 
makeup  of  the  list  will  be  intended  to  achieve  the  most  cost- 
effective  set  of  computers  possible;  computers  will  be  added 
to  the  list  and  listed  computers  will  be  replaced  by  improved 
computers  from  the  same  vendors  (upgrades) .  However,  the 
policy  is  not  likely  to  guarantee  that  the  listed  computers 
are  universally  on  the  leading  edge  of  technology  trends,  but 
it  can  improve  the  chances  that  the  computers  will  keep  pace 
with  these  trends. 

The  listed  computers  will  be  subject  to  guidelines 
for  design  specifications,  operational  and  functional  charac¬ 
teristics  as  well  as  reliability  characteristics  as  defined  by 
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military  environmental  standards^.  The  computers  will  also 
be  characterized  by  performance  characteristics  ( MTTR ,  MTBF , 
size,  etc.)  that  will  not  be  subject  to  rigid  standards. 

All  of  these  requirements  will  have  the  effect  of 
creating  engineering  commonality  within  the  list.  This  com¬ 
monality  will  correspond  roughly  to  the  current  standardiza¬ 
tion  approach  to  Navy  computers,  but  to  a  lesser  degree. 

The  list  of  accredited  computers  will  be  partitioned 
into  multiple  Performance  Ranges  (PRs)  defining  bounded  ranges 
of  computational  capability.  The  specification  of  the  charac¬ 
teristics  of  PRs  is  an  essential  factor  in  the  classification 
of  accredited  computers.  There  are  several  techniques  that 
can  be  used  to  define  PRs:  heuristic  classification,  classifi¬ 
cation  of  instruction  execution  time,  word  size,  etc.  and 
classification  based  on  performance  of  functional  tasks. 

•  Heuristic  classification  would  involve  using 
the  orderings  and  groupings  of  computers 
generally  employed  by  the  computer  industry. 
Those  classifications  are  typically  based  on 
an  intuitive  assessment  of  computer  character¬ 
istics  (word,  size,  etc.)  that,  over  time, 
change  and  blur  the  accepted  classifications. 

For  example,  the  classification  mini-computer 
spawned  super-mini  as  technology  advanced. 
However,  the  use  of  widely  used  classifications 
would  tend  to  align  the  Navy  with  the  computer 
industry  and  provide  consistency  of  terminology. 

•  Formulae  which  compute  overall  performance  on 
the  basis  of  instruction  execution  time,  word 
size,  memory  addressibility  and  data  transfer 
rates  are  sometimes  used  to  compare  computers. 


The  same  comparative  information  can  be  used 
to  classify  computers.  The  spectrum  of  per¬ 
formance  that  could  result  from  the  calculation 
could  be  broken  down  into  classes  (PRs)  that 
each  computer  could  be  mapped  onto. 

However,  minimal  success  has  been  achieved  with 
the  use  of  formulae  since  the  significance  of 
performance  parameters  vary  by  application  and 
because  differences  in  computer  design  make 
measurement  of  the  parameters  difficult6. 

This  approach  is  further  complicated  by  the 
fact  that  there  are  few  if  any  guidelines 
available  for  defining  the  boundaries  of  the 
capability  classes. 

•  A  third  way  of  defining  PRs  can  employ  bench¬ 
marks  representative  of  Navy  data  processing 
tasks.  The  tasks  performed  in  Navy  tactical 
systems,  of  course,  utilize  the  same  atomic 
computational  operations  as  business  or 
scientific  applications.  However,  response 
time  requirements,  data  volumes  and  applica¬ 
tion  types  (e.g.,  signal  processing  and 
weapons  control)  place  a  more  strenuous  per¬ 
formance  burden  on  embedded  computers.  There¬ 
fore,  benchmarks  at  a  level  somewhere  between 
atomic  operations  (individual  instructions) 
and  system  level  applications  (C3,  etc.)  could 
be  used  to  measure  expected  performance  of  Navy 
tasks. 

The  computational  characteristics  of  Navy  tasks 
can  be  defined  by  a  mix  of  three  performance 
parameters:  thousands  of  operations  per  second 
(XOPs) ,  data  transfer  rates  over  I/O  channels 


and  ability  to  respond  to  interrupts.  These 
three  parameters  appear  in  varying  mixes  in 
such  applications  as  command  and  control,  data 
management,  communications,  and  guidance  and 
control.  Available  computer  memory  is  not 
included  as  one  of  the  primary  parameters 
defining  computational  performance  since  each 
computer  can  generally  be  configured  with  a 
fairly  wide  range  of  memory  sizes.  Undoubtedly 
other  parameters  could  be  justified,  but  the 
use  of  the  three  least  arguable  parameters  will 
be  used  to  illustrate  a  way  of  defining  the  PRs. 

Each  PR  would  be  defined  on  the  basis  of  a  mix 
of  the  three  performance  parameters  with  each 
parameter  having  either  a  medium  or  high  level 
of  performance.  Thus,  eight  PRs  would  be 
defined.  The  range  of  high  or  medium  per¬ 
formance  would  have  to  be  defined  on  the  basis 
of  perceived  Navy  requirements.  Each  of  the 
eight  PRs  would  be  defined  by  a  range  of  per¬ 
missible  performance  for  each  of  the  three 
performance  parameters.  Benchmark  software 
for  each  of  the  three  performance  parameters 
would  be  executed  on  an  accredited  computer  to 
determine  the  PR  that  it  would  be  assigned  to. 

By  defining  PRs  on  the  basis  of  the  three  stated 
computational  performance  parameters,  the  shortcomings  of  the 
two  aforementioned  techniques  are  avoided;  definitions  of  PRs 
are  tied  to  Navy  tasks  rather  than  subjective  industry  terminology 
and,  thereby,  vary  only  as  a  function  of  the  proglem  domain;  the 
temptation  to  attempt  to  establish  a  single  value  definition  of 
performance  is  avoided. 


Each  PR  would  be  populated  by  at  least  two  computers. 
Each  accredited  computer  would  be  defined  by  computational  per¬ 
formance  (based  on  values  of  the  computational  performance 
parameters)  and  life  cycle  costs  as  a  function  of  unit  price 
and  performance  characteristics  (MTBF,  MTTR,  etc.).  The  presence 
of  multiple,  slightly  dissimilar  computers  would  create  competi¬ 
tion  in  the  RFP  and  FSED  stages  and,  as  well,  would  lead  to 
competitive  selections  of  accredited  computers  by  program  managers. 
Similarly,  multiple  computers  per  PR  would  provide  alternative 
choices  if  a  vendor  could  not  meet  production  requirements  of  a 
particular  program. 

However,  there  are  several  reasons  for  limiting  the 
number  of  accredited  computers  per  PR  to  three  or  four:  the 
competitive  gains  from  multiple  accredited  computers  are  not 
likely  to  be  as  great  for  four  or  more  computers;  the  portion 
of  the  market  represented  by  a  PR  that  a  vendor  is  likely  to 
get  declines  as  the  number  of  computers  in  a  PR  increase, 
thereby,  reducing  profit  attractions. 

One  might  assume  that  a  single  set  of  engineering 
standards  and  design  constraints  would  be  used  for  all  PRs 
within  the  list.  While  universal  standards  will  provide  some 
benefits  e.g.,  use  of  the  standard  ISA,  minimization  of  the 
multiplicity  of  training  programs,  other  costs  could  be  reduced 
if  subsets  of  engineering  standards  were  established. 

For  example,  segmenting  the  standards  into  compatible 
classes  (based  on  differences  in  capabilities  and  uses)  could 
allow  for  reduction  of  engineering  requirements  and  simplifica¬ 
tion  of  procurement  procedures  for  classes  having  less  rigorous 
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requirements.  The  segmentation  could  be  achieved  either  with 
multiple  lists  or  by  grouping  PRs  within  a  single  list.  In  the 
case  of  multiple  lists,  functional  characteristics  of  digital 
devices  (computational,  data  storage,  control,  interfacing/ 
data  transfer)  could  be  used  as  the  criteria  for  specifying 
the  different  lists.  With  a  single  list,  capability  would  be 
the  primary  factor  used  in  delineating  PRs.  Thus,  computers 
could  be  categorized  by  capability  within  functions. 

The  accreditation  of  a  computer  would  not  necessarily 
result  in  the  manufacture  of  production  models.  Instead,  pro¬ 
duction  models  would  be  built  only  in  response  to  a  purchase 
order  from  a  Program  Manager.  Therefore,  an  accredited  com¬ 
puter  might  never  go  into  production  and,  accordingly,  never 
be  used  in  a  tactical  system. 

It  must,  of  course,  be  possible  for  the  composition 
of  the  list  of  accredited  computers  to  change.  Allowing  these 
changes  will  avoid  locking  out  new  vendors  and  the  resulting 
reduction  in  competition.  Also,  changes  in  the  list  will  allow 
new  technology  to  be  acquired. 

A  strategy  will  be  required  for  controlling  the  addi¬ 
tion  of  computers  to  the  list.  By  definition,  the  variability 
of  computational  performance  within  a  particular  PR  will  be 
somewhat  limited.  Therefore,  a  computer  seeking  to  be  listed 
which  had  a  level  of  computational  capability  coinciding  with 
the  i*1*1  PR  would  be  compared  only  with  the  computers  in  that  PR. 

Thus,  computational  performance  would  not  be  a 
measure  for  comparison  but  rather  a  guide  for  determining  which 
subset  of  listed  computers  would  be  compared.  Accordingly,  the 
evaluation  of  a  candidate  computer  for  accreditation  would  have 
to  be  based  on  another  quantitative  measure,  such  as  life  cycle 


costs,  in  addition  to  validation  of  its  adherence  to  the  stip¬ 
ulated  accreditation  criteria.  The  characteristics  of  compari¬ 
sons  on  life  cycle  costs  are  discussed  in  the  following  sections. 

3. 2. 1.1. 2.1  Life  Cycle  Cost  Considerations  for  Accredited 

Computers . 

Computers  of  similar  computational  performance 
(i.e.,  of  the  same  PR)  will  be  compared  on  the  basis  of  life 
cycle  costs.  Total  life  cycle  costs  will  be  computed  for  each 
candidate  for  the  list.  The  computation  will  encompass  costs 
for  development  and  production  as  well  as  operations,  mainte¬ 
nance  and  support  for  the  computer.  O&M  costs  will  be  computed 
as  a  function  of  such  performance  characteristics  as  MTTR, 
training,  etc.  Once  costs  were  computed  they  would  be  compared 
to  the  costs  for  already  listed  computers.  A  decision  as  to 
whether  a  candidate  computer  should  be  accredited  would  be 
made  on  the  basis  of  the  life  cycle  cost  comparison  as  well  as 
the  results  of  accreditation  testing. 

In  general,  the  criteria  for  the  life  cycle  cost 
comparison  should  serve  to  drive  down  the  cost  of  each  suc¬ 
cessive  addition  to  the  list.  Thus,  the  decision  would  be 
made  to  list  a  candidate  computer  only  if  its  costs  compared 
favorably  to  those  of  listed  computers. 

The  life  cycle  cost  analysis  will  require  that 
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all  cost  elements  be  identified  and  quantified  '  '  .  The 
cost  elements  of  a  computer's  life  cycle  are  listed  in  Table  1 
in  the  approximate  order  in  which  they  arise.  Costs  incurred 
by  the  use  of  Navy  resources  to  perform  a  task,  as  well  as 
costs  reimbursed  to  the  vendor,  are  listed.  The  cost  elements 
from  proposal  review  through  completion  of  qualification  test¬ 
ing  are  grouped  as  a  Full  Scale  Engineering  Development  (FSED) 
effort.  The  cost  elements  from  purchase  through  field  changes 
relate  to  the  Operation  and  Maintenance  (O&M)  phase  of  the  com¬ 
puter's  life  cycle. 
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Table  1.  Computer  Life  Cycle  Cost  Elements 


Vendor  Responsibility 


Navy  Responsibility 


•  Proposal  review 


•  General  design 

•  Detailed  design 

•  Design  documentation 
development 

•  Prototype  development  & 
checkout 

•  Development  of  technical 
manuals 

•  Development  of  operator 
documentation 

•  Development  of  maintenance 
procedures 

(Maintenance  Requirements 
Cards) 

•  Development  of  Integrated 
Logistics  Support  Plan 

( ILSP) 

•  Production  of  Engineering 
Development  model 


•  Depot  set-up 


•  Review  of  technical  manuals 

•  Review  of  operator 
documentation 

•  Review  of  maintenance 
procedures 


•  Review  of  ILSP 


Accreditation  &  qualification 
testing  of  Engineering 
Development  model 

Purchase  of  production  models 

Acceptance  testing  of  pro¬ 
duction  models 


•  Spares  inventory  purchase  and 
administration 

•  Purchase  of  maintenance 
support  tools 

•  Maintenance  personnel 
training 

•  PM 

•  Organization  level  maintenance 
&  repairs 

•  Intermediate  level  repairs 

•  Depot  level  repairs 

•  Field  changes 
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3 . 2. 1. 1 . 2. 1 .1  Evaluation  of  Life  Cycle  Costs. 


Both  Policy  Administrators  and  Program  Managers 
would  perform  life  cycle  cost  analyses.  The  Policy  Administra¬ 
tor  would  actually  engage  in  two  analyses.  The  first  would  be 
performed  as  part  of  the  evaluation  of  a  proposal  for  a  candidate 
for  accreditation.  The  second  analysis  would  evaluate  a  com¬ 
puter's  suitability  for  accreditation  once  its  development  was 
completed.  Because  of  the  Policy  Administrator's  role  in  over¬ 
seeing  the  global  and  long  term  costs  to  the  Navy  for  all  com¬ 
puters,  his  evaluation  of  life  cycle  costs  must  provide  a  con¬ 
sistent  assessment  of  different  computers  over  the  long  term. 

On  the  other  hand,  the  Program  Manager's  life 
cycle  cost  analysis  would  be  based  more  on  the  planned  use  of 
the  computer  in  a  specific  application  or  system.  Thus,  more 
exact  values  for  purchase  quantity  and  price  and  expected  use¬ 
ful  life  span  would  be  used  in  the  analysis. 

The  life  cycle  cost  analyses  performed  by  both 
the  Policy  Administrator  and  the  Program  Manager  would  employ 
the  same  cost  formulas  and  values  for  Navy  costs. 

The  cost  elements  must  be  analyzed  to  assess 
both  their  potential  and  the  desired  impact  on  the  computer's 
life  cycle  costs  and  the  Navy's  goals  in  computer  acquisitions. 
Thus,  formulas  for  each  cost  element  must  be  set  up  to  reflect 
the  true  cost  of  each  element  to  the  Navy  and  by  so  doing 
define  targets  for  optimization  by  vendors  participating  in 
the  policy. 


The  goals  of  the  Accreditation  Policy  are 
actually  manifestations  of  costs  that  the  Navy  endeavors  to 
reduce  or  better  control.  Therefore,  the  life  cycle  cost 
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formulas  for  each  cost  element  must  reflect  those  cost  implica¬ 
tions.  The  cost  formulas  defined  in  MIL-STD-1390B10  provide  a 
complete  and  detailed  accounting  of  the  cost  elements  related 
to  O&M.  They  would  have  to  be  complemented  with  cost  formulas 
for  FSED  and  purchase  activities. 

3. 2. 1.1. 3  Potential  Vendors. 

In  its  attempt  to  attract  vendors,  the  Navy  must 
recognize  that  not  all  vendors  are  equally  compatible  with 
Navy  needs.  The  entire  spectrum  of  vendors  will  be  sought  as 
participants  in  the  accreditation  policy.  Even  so,  it  can  be 
surmised  that  the  following  types  of  vendors  will  be  more  likely 
to  participate: 

•  Vendors  willing  to  modify  their  own  or  others' 
products  to  satisfy  Navy  requirements .  (The 
development  of  militarized  versions  of  DEC  and 
Data  General  commercial  computers,  respectively 
by  Norden  and  Rolm,  are  examples  of  this  situa¬ 
tion.  Note  that  this  procedure  usually  results 

in  price  increases  of  a  factor  of  three  or  more  which 
is  the  inherent  price  of  militarization.) 

•  Vendors  who  are  seeking  to  maximize  their 
potential  market  by  striving  for  adaptable 
technology  (e.g.,  via  emulation)  and  who  are, 
therefore,  more  likely  to  have  the  capability 
to  accommodate  the  Navy's  requirements. 

•  Vendors  who,  on  a  company  or  division  level, 
see  the  Navy  as  a  viable  market  and  are  willing 

and  able  to  develop  complete  and  specialized  computer 
to  meet  the  Navy's  needs. 


3. 2. 1.1. 4  Encouraging  Vendor  Participation. 


Many  Navy  procurements  are  the  result  of  unsolicited 
ideas,  products  or  systems  from  vendors  or  contractors.  The 
list  of  accredited  computers  will  rely  almost  exclusively  on 
such  unsolicited  offerings.  Therefore,  the  Navy  must  take 
steps  to  ensure  that  such  offerings  are  forthcoming.  It  must 
"market"  or  encourage  vendors  in  the  sense  of  removing  implicit 
impediments,  thereby  making  it  easier  for  vendors  to  present 
their  ideas. 

The  Navy  can  represent  itself  as  a  more  receptive 
market  by  making  more  information  available  regarding  its  needs, 
plans,  procedures,  etc.  Some  vendors  are  often  discouraged  from 
the  Navy  market  because  of  a  simple  lack  of  information.  Some 
means  to  bridge  this  information  gap  (already  in  use  in  varying 
degrees)  might  include  industry  presentations;  informational 
contributions  to  industry  periodicals;  explanations  of  procedures; 
and  published  aids  for  the  production  of  required  DoD  documents. 
Several  of  these  actions  imply  that  a  single-minded  Navy  program 
can  be  formulated  for  presentation. 

3 . 2 . 1 . 1 . 5  Overview  of  an  Acquisition  Process. 

The  Accreditation  Program's  acquisition  philosophy 
must  be  suited  to  the  goals  and  exigencies  of  the  policy.  The 
acquisition  process  has  to  create  an  environment  that  promotes 
effective  price  and  performance  competition  for  Navy  computers 
while  providing  profit  incentives  for  vendors. 

The  acquisition  process  will  involve  (a)  the  issuance 
of  a  competitive  RFP  for  candidate  computers  for  accreditation, 

(b)  funding  for  the  parallel  development  of  engineering  models 
by  multiple  vendors  and  (c)  evaluation  of  the  completed  candi¬ 
dates.  The  up-front  funding  of  multiple  FSED  efforts  results 
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in  increased  costs  that  should  be  offset  by  the  exertion  of 
competitive  forces  on  overall  Navy  costs.  Navy  development 
funding  would  be  intended  to  expedite  packaging  of  state-of-the 
art,  proven  technology  for  Navy  use,  rather  than  to  support 
the  development  of  the  logic  technology  itself.  It  must  be 
assumed  that  the  demands  of  the  commercial  market  place  will 
lead  to  advances  in  logic  technology  without  Navy  funding  of 
R&D. 


The  acquisition  process  would  be  initiated  with  the 
issuance  of  an  RFP  for  candidate  computers  for  a  particular  PR. 
The  proposals  would  be  required  to  specify  the  technology  base 
for  the  computer  and  how  the  accreditation  requirements  would 
be  satisfied  (with  supporting  rationale  and  data) .  If  the 
proposed  computer  seemed  to  be  technologically  promising,  if 
there  appeared  to  be  a  good  likelihood  of  successful  completion 
within  costs,  and  if  the  computer’s  projected  life  cycle  costs 
were  competitive  with  those  of  previously  accredited  computers, 
the  development  effort  would  be  approved  and  funded. 

By  providing  up-front  funding  of  FSED  efforts,  the 
Navy  ensures  that  state-of-the-art  computers  are  readily  avail¬ 
able  for  selection  and  use  in  tactical  systems.  Therefore,  the 
Navy  avoids  the  situation  wherein  the  system  development  cycle 
is  lengthened  by  the  time  needed  to  develop  the  required  com¬ 
puter  technology.  In  essence,  the  expenditure  of  FSED  funds 
to  perfect  fully  militarized  computers  effectively  eliminates 
availability  of  up-to-date  computer  technology  as  one  of  the 
risk  factors  in  the  development  of  tactical  systems. 

Typically,  funding  for  the  FSED  of  candidate  com¬ 
puters  would  be  provided  by  the  Policy  Administrator.  However, 
there  would  be  no  prohibition  on  a  Program  Manager  funding  the 
development  of  a  computer  for  a  specific  program.  The  resultant 
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computer  would  still,  however,  have  to  undergo  accreditation 
evaluation  and  prove  its  cost-effectiveness  before  it  could  be 
used  in  a  shipboard  system.  This  arrangement  would  give  Program 
Managers  a  little  more  flexibility  in  acquiring  needed  computers 
while  providing  a  funding  source  other  than  the  Policy  Adminis¬ 
trator's  office. 

Major  decision  points  would  be  established  during 
the  development  effort  to  allow  for  cancellation  in  the  event 
of  failure  by  the  vendor  to  successfully  meet  a  milestone.  The 
Navy  would,  of  course,  have  the  option  to  continue  funding 
despite  a  milestone  failure  if  so  warranted  by  the  product's 
promise. 

Upon  completion  of  FSED,  the  computer  would  be 
evaluated  with  respect  to  its  compliance  with  the  accreditation 
criteria.  Additionally,  its  life  cycle  costs  would  again  be 
computed  and  compared  to  those  of  previously  accredited  com¬ 
puters.  If  the  candidate  computer  passed  the  accreditation 
evaluation,  it  would  be  added  to  the  list  of  accredited  com¬ 
puters.  Once  listed,  accredited  computers  would  be  treated  as 
commodities  available  for  special  order. 

The  proposed  acquisition  process  is  tied  to  the 
characteristics  of  the  concept  of  accreditation.  Not  surpris¬ 
ingly,  it  differs  from  the  two  most  commonly  used  acquisition 
processes:  (1)  award  of  a  single  contract  for  FSED  on  the  basis 
of  an  evaluation  of  competitive  proposals  and  (2)  leader- 
follower  acquisitions.  The  proposed  process  encourages  price 
and  performance  competition  throughout  the  acquisition  process 
whereas  the  single  contract  method  encourages  competition  only 
for  the  proposal  stage.  The  funding  of  parallel  FSED  efforts 
is  the  price  that  is  paid  for  that  additional  competition. 


The  proposed  acquisition  process  also  involves  some 
differences  with  the  leader-follower  process.  The  leader- 
follower  procedure  encourages  competition  for  the  proposal, 

FSED  and  procurement  stages.  As  with  accreditation,  increased 
costs  result  from  the  funding  of  multiple  FSED  efforts,  in  this 
case  for  both  the  leader  and  follower  of  the  teams  that  win  the 
proposal  effort.  The  implementation  of  a  single  technology  by 
both  the  leader  and  follower  can  reduce  O&M  costs  for  the  com¬ 
pleted  computer.  However,  this  lack  of  diversity  can  result 
in  less  technological  innovation  than  if  both  vendors  worked 
independently.  Also,  long  term  technology  stagnation  can  be 
avoided  only  by  going  through  the  acquisition  process  again 
in  the  future  to  take  advantage  of  technology  advances.  How¬ 
ever,  if  a  different  design  is  selected  in  a  subsequent  acquisi¬ 
tion,  O&M  is  impacted  as  much  as  it  would  have  been  if  more 
than  one  design  had  been  chosen  in  the  initial  procurement. 

With  the  leader -follower  arrangement  there  is  less 
potential  for  price  competition  for  a  buy  than  with  accredita¬ 
tion.  When  the  leader  and  follower  become  competitors  for  the 
production  phase,  they  are  each  awarded  a  proportion  of  the 
buy.  However,  unless  a  stipulated,  preponderent  proportion 
will  be  awarded  to  the  vendor  with  the  lowest  unit  price, 
there  will  not  be  enough  incentive  to  encourage  rigorous  com¬ 
petition.  On  the  other  hand,  the  Accreditation  Policy  provokes 
fiercer  competition  since  each  complete  system  buy  is  available 
for  bid. 


The  decision  of  which  proposed  computers  to  fund  for 
development  is  a  critical  one  in  ensuring  that  total  costs  of 
computers  decrease  as  a  result  of  the  Accreditation  Policy;  the 
cost-effectiveness  of  proposed  technology  must  be  evaluated  to 
ensure  price  and  performance  gains  from  competition.  One  of 
two  alternative  schemes  can  be  used  in  determining  the  efficacy 


of  the  proposed  technology:  a  subjective  evaluation  or  an 
evaluation  based  on  periodic  quantitative  analysis  of  life 
cycle  costs  of  accredited  and  proposed  computers. 

3. 2. 1.1. 5.1  Subjective  Technology  Evaluation. 

In  the  subjective  approach  to  evaluating  proposed 
technology,  the  proposal  evaluators  would  use  professional 
judgment  to  determine  if  the  technology  advanced  the  Navy's 
goals.  The  O&M  costs  of  already  accredited  and  proposed  com¬ 
puters  could  be  compared  to  gain  a  perspective  on  their  relative 
cost-effectiveness.  Funding  would  be  approved  for  those  pro¬ 
posed  computers  deemed  promising.  The  number  that  would  be 
funded  would  depend  on  the  size  of  the  available  budget.  Pro¬ 
posals  would  be  evaluated  annually  to  facilitate  the  funding 
decision.  Every  funded  computer  receiving  accreditation  would 
be  added  to  the  list  of  accredited  computers. 

The  comparison  of  costs  could  be  performed  by  com¬ 
puting  the  average  of  the  O&M  life  cycle  costs  for  the  computers 
already  accredited.  The  life-cycle  costs  would  be  computed  with 
the  aforementioned  cost  formulas  on  the  basis  of  a  "reasonably 
likely"  purchase  quantity  based  on  past  experience.  The  average 
cost  (PRav)  for  previously  accredited  computers  in  a  PR  and  the 
standard  deviation  of  PRAV  (PRgD)  wou^  be  computed.  If  the 
life  cycle  costs  for  a  candidate  computer  were  less  than,  say, 
PRAV  -  PRgD,  the  computer  would  be  eligible  for  accreditation. 
This  method  of  comparison  sets  a  ceiling  on  costs  instead  of 
providing  a  specific  cost  measure  of  technological  improvement 
that  a  candidate  would  have  to  achieve.  However,  the  removal 
of  more  costly  computers  from  the  list  to  maintain  three  to  four 
per  PR  would  have  the  effect  of  lowering  the  ceiling. 
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3 . 2 . 1 . 1 . 5 . 2  Quantitative  Technology  Evaluation. 

The  alternative  approach  to  funding  decisions 
involves  more  quantitative  evaluative  methods.  When  the  RFP 
for  candidates  for  accreditation  is  issued,  newly  proposed 
(as  yet  unfunded)  computers  as  well  as  previously  funded  and 
accredited  computers  would  be  directly  compared.  The  life 
cycle  costs  for  both  types  of  computers  would  be  computed  on 
the  basis  of  any  required  development  effort,  O&M  costs  and 
the  total  projected  computer  buy  for  the  period  of  three  to 
four  years  from  the  accreditation  evaluation  (approximately 
two  years  hence) .  The  computed  life  cycle  costs  provide  a 
quantified  but  relatively  heuristic  basis  for  comparison  since 
a  single  accredited  computer  would  not,  in  fact,  be  dictated 
for  the  total  projected  buy.  Thus,  the  technology  of  proposed 
computers  would  have  to  yield  a  sizeable  enough  reduction  in 
life  cycle  costs  to  better  the  costs  of  already  accredited 
computers  whose  previously  funded  development  costs  would  not  be 
included.  This  comparison  is  represented  in  Figure  2.  To 
maintain  three  accredited  computers,  Computers  Pi  and  P2  would 
be  approved  for  funding.  Computer  P3  would  not  be  funded  and 
Al  would  lose  accreditation  after  t+2.  Computers  Pi,  P2  and 
A2  would  be  the  available  accredited  computers  for  the  period 
t+2  to  t+5. 


The  number  of  development  efforts  to  be  funded  in 
each  RFP  cycle  would  depend  upon  the  number  that  bettered 
already  accredited  computers  and  would,  therefore,  be  unpre¬ 
dictable.  However,  the  goal  would  be  to  fund  enough  so  that 
once  those  funded  were  accredited,  there  would  be  a  mix  of 
previously  accredited  and  newly  accredited  computers  totaling 
three  or  four.  With  this  method,  previously  accredited  com¬ 
puters  would  undergo  periodic  comparison  with  new  computers 
and  would  be  subject  to  being  removed  from  the  list. 
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A1 ,A2  -  ACCREDITED  COMPUTERS  0 1  AND  02 
PI ,P2 ,P3  -  PROPOSED  CANDIDATE  COMPUTERS  01,  02,  AND  *3 
Cl ,C2,C3  -  FSED  COSTS  FOR  PI,  P2  AND  P3 

t-TIME  AT  WHICH  FUNDING  DECISION  IS  MADE  FOR 
PROJECTED  BUY  OF  n  COMPUTERS  FOR  PERIOD 
t+2  TO  t+5 


Figure  2 .  Life  Cycle  Cost  Comparison  of 

Accredited  and  Proposed  Computers 


Projecting  the  life  cycle  costs  for  a  three  to 
four  year  period  gives  the  Policy  Administrator  a  reasonable 
quantity  base,  over  a  period  of  relative  technological  stability, 
upon  which  to  credibly  minimize  Navy  costs.  However,  the  list¬ 
ing  of  multiple  computers  will  probably  result  in  a  smaller 
actual  buy  for  each  computer  and,  therefore,  different  cost 
from  the  projection  depending  on  the  size  of  each  of  the  buys. 
(The  continued  minimization  of  costs  in  conjunction  with  the 
Program  Manager's  evaluation  of  listed  computers  is  discussed 
in  Section  3. 2. 1.3. 4.) 

3. 2. 1.1. 6  Reorganization  of  Qualifications  for  Operational  Use. 

The  Navy  endeavors  to  obtain  cost-effective  products 
by  using  well  defined  procurement  procedures  and  product  stan¬ 
dards  (MIL-STDS) .  Some  of  the  procedures  and  standards 
(specifically  as  embodied  in  Approval  for  Service  Use  (ASU) 
address  computers  from  the  dual  perspective  of  hardware  and 
operational  effectiveness.  ASU  requires  that  several  certifi¬ 
cations  be  undertaken: 

•  The  computer  undergoes  qualification  testing  to 
verify  that  it  satisfies  applicable  MIL-STDSs. 

•  An  Integrated  Logistics  Support  Plan  (ILSP)  is 
generated  which  specifies  a  methodology  for 
logistically  supporting  the  computer. 

•  An  Operational  Test  (OT&E)  is  performed  to 
validate  both  the  operational  effectiveness  of 
the  computer  (in  and  of  itself  as  well  as  part 
of  a  system)  and  the  viability  of  the  ILSP  in 
practice. 

The  Accreditation  Policy  can  be  strengthened  by 
assigning  it  responsibility  for  certification  of  all  of  the 
hardware  and  some  of  the  operational  characteristics.  This 


approach  will  allow  the  computer  to  be  viewed  as  an  entity  unto 
itself  for  accreditation  purposes.  In  addition,  the  apportion¬ 
ment  of  responsibility  will  allow  as  much  verification  as  pos¬ 
sible  to  be  performed  when  the  computer  is  listed.  The  per¬ 
formance  of  testing  (benchmarks,  etc.)  during  the  accreditation 
phase  can  reduce  both  overall  costs  for  the  OT&E  as  well  as  the 
time  elapsing  between  selection  of  the  computer  and  its  use  on 
board  a  ship.  These  benefits  are  currently  evidenced  in 
standardized  computers  which  have  been  approved  for  service  use. 

The  vendor  will  have  responsibility  for  ensuring  that 
the  computer  satisfies  the  design  constraints  and  engineering 
standards  defined  by  the  Policy  Administrators  as  criteria  for 
accreditation.  The  vendor  will  also  be  responsible  for  pro¬ 
viding  a  practicable  ILSP.  Operational  aspects  of  the  ILSP 
will  be  verified  as  part  of  accreditation  testing,  where  feasible. 
The  ability  of  the  computer  to  be  used  effectively  as  part  of  an 
operational  capability  (including  the  viability  of  the  complete 
ILSP)  will  be  verified  by  the  system’s  Program  Manager/Developing 
Agency  via  Developmental  Test  and  Evaluation  ( DT&E)  as  well  as 
during  OT&E. 

3 . 2 . 1 . 1 . 7  Profit  Inducements. 

Ultimately,  vendors  will  be  attracted  to  participate 
in  the  Accreditation  Program  by  the  expectation  of  adequate 
profits.  The  Navy's  funding  of  the  development  of  a  candidate 
computer  will,  of  course,  provide  some  profits.  Furthermore, 
profits  would  be  realized  for  any  production  units  purchased  by 
Program  Managers  for  use  in  shipboard  systems.  The  magnitude 
of  these  profits  will  be  largely  a  function  of  the  number  of 
computers  sold. 
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By  allowing  only  three  or  four  accredited  computers 
in  each  PR,  the  policy  will  keep  the  potential  market  share  for 
each  vendor  at  a  level  compatible  with  the  aim  of  gaining  com¬ 
petition.  However,  a  vendor  could  increase  his  potential  market 
size  by  developing  a  family  of  computers  that  encompassed  multi¬ 
ple  PRs  and  their  associated  expected  purchase  quantities. 

Because  the  same,  or  very  similar,  technology  and  packaging 
would  be  used  for  the  entire  family,  the  development  costs  and 
purchase  price  for  each  PR's  computer  should  be  lower  than  if 
only  a  single  computer  were  offered  by  the  vendor. 

The  use  of  families  of  computers  would  also  make  the 
vendor's  computers  more  competitive  with  regard  to  the  FSED  or 
production  cost  factors  of  life  cycle  costs.  The  FSED  costs 
for  each  successive  member  of  the  family  could  be  expected  to 
be  lower  because  of  the  repeated  reapplication  of  existing 
technology.  If  all  the  family  members  were  submitted  at  the 
same  time,  the  FSED  cost  for  each  could  be  estimated  as  the 
total  FSED  cost  divided  by  the  number  of  members.  Production 
and  other  costs  (logistics,  training,  etc.)  could  also  be  reduced 
if  the  larger  potential  market  made  accessible  by  a  family  line 
yielded  a  larger  realized  market  and  economies  of  scale. 

3 . 2 . 1 . 2  Maintenance  Support  Requirements. 

Analysis  performed  by  the  Navy  indicates  that  the 
number  of  embedded  computers  in  use  will  grow  significantly  in 
coming  years  .  On  the  other  hand,  studies  show  that  the 
number  of  skilled  people  available  to  operate  and  maintain 
computer  systems  will  not  keep  pace  with  that  growth.  The 
increased  number  of  computers  will  also  require  that  training 
of  personnel  (in  either  diversity  or  detail)  be  adjusted  to 


handle  the  required  system  maintenance.  The  Accreditation 
Policy  should,  therefore,  provide  some  means  of  accommodating 
these  demands. 


3 . 2 . 1 . 2 . 1  Reduction  of  Maintenance  and  Training  Requirements. 

One  of  the  major  costs  of  embedded  computers  is  tied 
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to  the  cost  of  labor  intensive  maintenance  '.  Accordingly, 
ways  to  reduce  these  costs  are  of  considerable  interest.  How¬ 
ever,  it  should  not  be  expected  that  the  Accreditation  Policy 
will  embody  explicit  requirements  or  procedures  for  reducing 
these  costs.  Rather  the  policy  should  point  out  the  importance 
of  reducing  the  cost  of  critical  maintenance  elements. 

As  methods  and  technology  evolve  and  mature  that 
can  supplant  labor  intensive  maintenance  activities,  the  Navy 
(perhaps  at  the  behest  of  the  Policy  Administrator)  must 
develop  a  new  maintenance  plan  (i.e.,  who  performs  maintenance 
and  how  it  is  performed)  to  reduce  the  cost  of  maintenance 
training  and  maintenance  activities.  An  appropriate  marriage 
of  technology  trends  and  policy  goals  is  outlined  in  the  follow¬ 
ing  sections.  The  discussion  below  is  applicable  to  both  the 
Policy  Administrator  and  the  vendor  since  it  provides  a  greater 
appreciation  for  critical  concerns  and  ways  in  which  they  could 
be  handled. 


3. 2. 1.2. 1.1  A  New  Maintenance  Plan. 

The  maintenance  plan  can  exploit  a  trend  already 
extant  in  the  computer  industry,  i.e.,  design,  construction  and 
maintenance  at  the  card  level.  Accordingly,  the  card  would  be 
the  Least/Line  Replaceable  Unit  (LRU)  for  maintenance  purposes. 

Reliance  on  card  level  maintenance  will  require  that 
computers  for  the  Navy  be  designed  to  facilitate  problem  diagnosis 
and  parts  replacement  at  the  card  level. 
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A  card  taken  from  the  spares  inventory  to  repiace 
a  failed  card  can  be  replenished  in  one  of  two  ways:  (1)  rotatable 
parts  pool  -  the  failed  card  can  be  sent  to  one  of  the  mainte¬ 
nance  unit  levels,  repaired  and  returned  to  the  inventory  at 
the  appropriate  maintenance  level  or  ( 2)  throwaway  plan  -  the 
failed  card  is  discarded  and  replaced  from  inventory  and  a  newly 
purchased  replacement  card  provided  to  the  appropriate  mainte¬ 
nance  level  inventory.  The  costs  of  these  respective  methods 
must  be  computed  to  identify  the  most  cost-effective  method  to 
manage  the  inventory  for  each  card. 

The  design  of  cards  must  be  optimized  so  that  the 
cards  (1)  entail  a  level  of  detail  and  complexity  that  is  not 
too  expensive  for  sparing  and  (2)  are  functionally  specified  so 
that  they  are  conducive  to  the  isolation  of  problems  to  a 
specific  card.  Thus,  the  card  must  be  modular  and  functionally 
independent  of  other  cards. 

There  are  definite  industry  trends  toward  the  use 
of  software  and  firmware-based  system  diagnostics  capabilities 
that  can  perform  lower  echelon  maintenance  e.g.,  the  identifica¬ 
tion  of  functionally  inoperative  LRUs  (permanent  or  recurring 
failures)  via  PM  and  problem  diagnosis^ These  tools 
require  that  the  function  of  LRUs  be  well  defined  and  modular. 
However,  these  diagnostics  often  still  require  highly  skilled 
technicians  to  interpret  and  react  to  their  results.  Nonethe¬ 
less,  these  capabilities  should  be  exploited  to  expedite  problem 
identification  and  correction.  Accordingly,  an  even  greater 
share  of  the  diagnosis  involved  in  lower  echelon  maintenance 
could  be  shifted  to  the  system  itself. 

To  carry  that  trend  even  further,  less  skilled 
operator  personnel  could  be  trained  to  use  the  system  diagnostics. 
While  this  would  entail  additional  training  for  this  group,  the 
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increase  should  be  minimal  if  the  diagnostics  are  truly  effective 
and  easy  to  run.  Training  would  be  limited  to  operation  of  the 
diagnostics  and  replacement  of  parts  identified  as  inoperative, 
as  opposed  to  analytical  troubleshooting.  Thus,  more  highly 
skilled  technicians  can  be  released  from  lower  echelon  mainte¬ 
nance  tasks,  thereby,  reducing  the  scope  of  tasks  they  have  to 
perform.  This  ability  of  relatively  low  cost  diagnostic  aids 
to  significantly  reduce  skill  requirements  for  lower  echelon 
maintenance  may  represent  the  greatest  potential  for  reducing 
maintenance  costs  in  light  of  currently  experienced  low  MTTR 
(15-45  minutes) . 

Although  diagnostics  are  usually  computer  specific, 
guidelines  (not  standards)  for  their  capabilities  and  operation 
should  be  promulgated  by  the  Navy  to  make  them  more  utilitarian. 
Even  if  system  diagnostics  are  effectual,  upper  echelon  mainte¬ 
nance  involving  sophisticated  analysis  and  troubleshooting  will 
be  required  for  field  changes  and  for  significant  problems  as 
follows: 


•  Errors  not  addressed  by  the  system  diagnostics. 

•  Problems  related  to  hardware  design  shortcom¬ 
ings  and  experiended  only  under  operational 
conditions . 

•  Failures  prohibiting  execution  of  the  system 
diagnostics. 

Therefore,  the  skills  required  for  upper  echelon  maintenance 
must  still  be  in  place. 

Personnel  performing  upper  echelon  maintenance 
have  to  be  trained  in  analytical  techniques  in  addition  to 
having  at  least  a  basic  familiarity  with  the  logic  diagrams  of 


the  computer.  They  will  also  benefit  from  documentation 
describing  the  data  flow  of  the  system,  on  at  least  a  func¬ 
tional  level,  since  problems  are  often  intimately  linked  to 
the  operational  use  of  the  equipment. 

To  further  increase  the  productivity  of  upper 
echelon  maintenance,  state-of-the-art  diagnostic  and  test 
equipment  should  be  on  hand.  Equipment  such  as  logic  and  data 
analyzers  should  be  as  commonly  available  and  in  use  as  oscil¬ 
loscopes  ^ . 


It  is  also  feasible  to  reduce  the  training  and 
workload  for  maintenance  personnel  by  changing  the  type  of 
maintenance  for  which  they  are  responsible.  For  example,  some 
rates  (typically  DSs)  perform  all  types  of  maintenance  from  PM 
to  troubleshooting,  using  logic  charts  and  scopes.  This  task¬ 
ing  increases  both  the  level  of  training  that  these  rates  must 
have  and  the  magnitude  of  their  workload.  By  segmenting  the 
overall  workload  into  lower  and  upper  echelon  tasks,  available 
skills  can  be  better  matched  to  the  requirements  of  the  tasks. 

In  conjunction  with  this,  available  and  developing  maintenance 
technology  could  be  used  to  both  .facilitate  the  segmentation  of 
the  workload  and  complement  the  skills  employed  for  the  tasks  , 
thereby  reducing  the  associated  workload.  For  example,  lower 
and  upper  echelon  tasks,  respectively,  could  be  assigned  to 
(a)  Data  Processing  Technicians  (DPs)  and  Data  System  Techni¬ 
cians  (DSs)  or  (b)  DSs  (or  DPs)  and  Mobile  Technical  Unit  (MOTU) . 

Decreases  in  the  cost  of  computers  themselves  or 
their  LRUs  may  become  so  significant  that  throwaway  will  become 
the  predominant  parts  replacement  method.  When  that  point  is 
reached,  the  proposed  subdivision  of  maintenance  tasking  will 
facilitate  the  substitution  of  a  comprehensive  throwaway  mainte¬ 
nance  plan  for  most  upper  echelon  maintenance. 


3. 2. 1.2. 1.2 


Reducing  the  Likelihood  of  Computer  Malfunctions. 


The  maintenance  workload  can  be  further  alleviated 
by  reducing  the  likelihood  of  computer  malfunctions.  One  way 
to  achieve  this  would  be  to  develop  simpler,  less  problematic, 
functional  level  design.  In  other  words,  design  characteristics 
that  are  functionally  complex  and  involve  more  complex  hardware 
or  logic  should  be  avoided.  An  example  of  this  in  some  current 
Navy  computers  is  the  grouping  of  I/O  channels  as  chassis 
(rather  than  treating  them  completely  independently) .  Use  of 
chassis  has  been  hypothesized  as  the  cause  of  numerous  inter¬ 
mittent  or  obscure  hardware  problems.  Simplicity,  perhaps  at 
slightly  higher  design  or  production  cost,  should  be  the  design 
goal . 


Another  significant  factor  in  the  amount  of  required 
maintenance  for  a  computer  is  the  amount  of  shakedown  testing 
performed  prior  to  field  use.  Navy  experience  has  shown  that 
computers  introduced  too  "quickly"  have  experienced  a  high 
failure  rate  until  initial  production  and  design  problems  were 
worked  out.  Requiring  more  extensive  acceptance  testing  prior 
to  installation  could  reduce  the  requirement  for  shipboard 
maintenance  at  the  time  when  maintenance  personnel  are  least 
capable  of  performing  it. 

The  age,  design,  etc.  of  today's  embedded  computers 
are  the  most  frequently  cited  causes  of  malfunctions.  However, 
in  the  shipboard  environment,  the  stress  placed  on  computers  by 
means  of  the  power  source  is  also  significant;  there  are  frequent 
instances  of  power  supply  problems  that  are  both  intentional 
(drills  requiring  power  curtailment,  shifts  between  shore  power 
and  ship's  own  power,  etc.)  and  inadvertent  (power  supply 
failures,  brownouts,  surges,  etc.)  that  undoubtedly  contribute 
to  intermittent,  delayed  or  immediate  failures.  Bringing  more 
control  and  order  to,  at  least,  the  intentional  anomalies  should 
lead  to  an  overall  reduction  in  system  problems. 


3. 2. 1.2. 2 


Maintaining  Adequate  Computer  Availability. 


Despite  the  expected  imbalance  in  the  number  of  com¬ 
puters  in  use  and  the  maintenance  personnel  available  to  support 
them,  adequate  availability  of  the  computers  must  be  achieved. 

Therefore,  varied  means  will  have  to  be  pursued  to  ensure  adequate 
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operational  availability 

The  reliability  of  militarized  equipment  that  is 
generally  in  use  is  significantly  lower  than  that  for  commercial 
computers  and  newer  militarized  computers,  as  well.  Therefore, 
the  increasing  reliability  of  state-of-the-art  hardware  can  be 
expected  to  provide  a  significant  improvement  over  current  Navy 
computers.  Today's  technology  is  more  reliable  by  virtue  of 
improved  production  techniques,  more  sophisticated  but  clearer 
design  and  efficient  use  of  less  expensive  technology.  Com¬ 
mercial  computers  are,  however,  not  designed  or  constructed  in 
accommodation  of  the  Navy's  engineering  standards.  Therefore, 
it  will  still  be  necessary  to  provide  adaptions  for  the  military 
environment. 


The  use  of  military  reliability  and  environmental 
standards  for  engineering  provides  a  significant  increase  in 
component  and  IC  reliability.  In  fact,  most  of  the  standards 
are  so  stringent  that  mere  mention  of  them  allays  most  apprehen¬ 
sion  about  reliability.  The  effectiveness  of  the  standards, 
however,  comes  at  a  very  high  monetary  price.  The  sense  of 
security  that  is  bought  with  these  standards  may  result  in 
reliability  overkill  and  unnecessarily  costly  components  and, 
ultimately,  systems.  The  existence  of  varying  levels  of 
standards  (e.g.,  MIL-STD  883  classes  A,  B  and  C  with  and  with¬ 
out  JAN  compliance)  argues  for  better  matching  of  expected 
environmental  stress  conditions  with  adequate  (not  excessive) 
standards.  The  possibility  of  buying  components  or  even  com¬ 
puters  suited  to  their  expected  environmental  stress  requirements 
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becomes  more  feasible  under  the  proposed  policy;  computers  will 
be  built  most  often  in  response  to  a  particular  requirement  for 
a  buy. 


Measures  of  the  operational  availability  of  computers 
should  not  be  based  solely  on  the  durability  (MTBF)  of  the 
equipment.  Instead,  other  factors  should  be  explored  to  ensure 
required  availability.  The  MTTR  can  provide  a  significant  con¬ 
tribution  if  considered  in  conjunction  with  the  proposed  new 
maintenance  plan.  In  that  regard,  the  ease  with  which  the 
equipment  can  be  repaired  due  to  the  card  level  design  and 
maintenance  as  well  as  the  allocation  of  maintenance  tasking 
and  the  use  of  good  diagnostic  tools  can  each  be  an  indispens¬ 
able  complement  to  MTBF. 

System  configuration  (e.g.,  loosely  coupled  or  dis¬ 
tributed  architectures)  can  reduce  the  criticality  of  an 
individual  computer.  That  would  reduce  the  likelihood  of  a 
system  failure  resulting  from  a  single  computer  failure.  In 
addition,  the  reliability  and,  therefore,  the  operational 
availability  of  a  system  could  be  improved  with  the  use  of 
redundant  computers.  Standby  redundancy  (cold  spares)  and 
operating  redundancy  (hot  spares)  can  be  utilized  to  increase 
operational  availability  even  though  MTBF  and  MTTR  would  not 
necessarily  be  improved.  Redundancy  and  creative  system  con¬ 
figurations  may  provide  more  cost-effective  improvements  in 
operational  availability  than  reliance  on  advances  in  reli¬ 
ability  and  maintainability. 
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3. 2. 1.3  Acquiring  Improved  Technology. 


Accredited  computers  can  be  expected  to  provide  increases 
in  computational  performance  and  reliability  as  a  result  of  the 
use  of  state-of-the-art  logic  technology  as  well  as  improved  func¬ 
tional  design.  However,  the  Navy's  goals  will  be  achieved  in  toto, 
if  and  only  if,  the  improved  technology  can  be  obtained  for  prac¬ 
tical,  in-the-field  use  on  a  timely  basis.  Therefore,  the  pro¬ 
posed  policy  must  ensure  that  the  computers  themselves  as  well  as 
policy  procedures  expedite  the  field  use  of  the  accredited  com¬ 
puters  . 


3. 2. 1.3.1  Acquiring  Commercial  Technology. 

The  proposed  business  relationship  between  the  Navy 
and  commercial  vendors  is  the  first  step  along  the  path  of  acquir¬ 
ing  commercial  technology  for  use  in  shipboard  systems.  (It  must 
be  stressed  that  the  Accreditation  Policy's  practical  goal  is  the 
acquisition  of  the  technology  of  the  commercial  world  rather  than 
off-the-shelf  commercial  computers  themselves.)  Additionally, 
steps  must  be  taken  to  get  the  production  version  of  the  engineer¬ 
ing  development  models  into  the  fleet. 

The  commercial  technology  packaged  for  Navy  use  must, 
of  course,  be  able  to  satisfy  the  Reliability  and  Maintainability 
(R&M)  requirements  of  the  shipboard  environment.  The  increased 
reliability  that  attends  technology  advances  is  not  likely  to 
satisfy  those  requirements,  especially  as  related  to  humidity, 
salt  spray,  EMI,  etc.  Therefore,  the  commercial  technology  will 
probably  have  to  be  repackaged  or  adapted  to  satisfy  R&M  require¬ 
ments.  The  repackaging  could  occur  on  any  or  all  of  several  levels 
replacement  of  commercial  grade  components  with  MIL-STD  components, 
redesign  of  card  construction  or  redesign  of  card  or  cabinet  lay¬ 
out. 
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It  could  be  argued  that  continued  miniaturization  of 
digital  circuitry  and  increasing  reliance  on  throwaway  mainte¬ 
nance  could  lead  to  the  satisfaction  of  many  environmental  stand¬ 
ards  by  means  of  complete  encasement  of  circuits.  However,  encas¬ 
ing  circuits  in  an  effective  "insulating"  material  would  require 
the  development  of  other  technology  (e.g.,  for  dissipation  of  heat) 
comparable  in  sophistication  to  the  environmental  standards  them¬ 
selves.  Therefore,  environmental  standards  should  continue  to  be 
a  requirement  of  militarization  for  some  time  to  come. 

3. 2. 1.3. 2  Getting  Improved  Computers  Accredited. 

Seldom  is  a  device  (no  matter  how  widely  it  is  used  in 
the  commercial  world)  added  to  the  Navy's  inventory  until  an 
explicit  requirement  for  it  is  stated  and  extensively  confirmed. 

This  conservative  approach  helps  to  reduce  the  chance  that  unneeded 
capabilities  are  developed.  However,  it  also  tends  to  delay  the 
operational  availability  of  a  capability.  The  Navy  should  strive 
to  identify  capabilities  that  have  "obvious"  utility  and  ensure 
that  they  are  added  to  the  list  of  accredited  computers  for  eventual 
use.  This  approach  would  be  similar  to  that  of  R&D  in  general:  a 
reasoned  investment  made  in  development  in  an  effort  to  anticipate 
highly  probably  requirements.  Lagging  operational  availability 
is  likely  to  remain  a  problem  if  the  current  reactive  practices 
continue. 


The  most  obvious  point  at  which  there  is  a  need  to 
anticipate  requirements  is  with  the  initial  set  of  listed  com¬ 
puters.  It  may  be  necessary  for  the  Navy  to  (a)  submit  an  RFP  to 
the  Navy's  traditional  vendors  to  get  the  program  underway,  (b) 
waive  some  qualifications  to  facilitate  initial  development  or  (c) 
provide  extraordinary  funding  as  an  incentive  to,  or  to  permit, 
accelerated  development.  Existing  approved  computers  can,  of 
course,  be  placed  on  the  list  and  administered  in  line  with  the 
Accreditation  Policy.  Also,  the  goal  should  be  to  populate  every 
PR  with  at  minimum  two  accredited  computers. 


47 


3. 2. 1.3. 3  Minimizing  Delays  of  the  Policy. 

There  are  numerous  factors  (in  addition  to  the  actual 
computer  development  cycle)  that  delay  the  introduction  of  a  new 
computer  into  the  field.  Some  of  the  delay  is  related  to  the 
validation  of  the  computer's  operational  effectiveness.  While 
it  is  not  assumed  that  the  Policy  Administrators  can  impact  opera¬ 
tionally  related  issues,  the  delays  inherent  in  the  accreditation 
testing  must  be  minimized  as  much  as  practical.  Facility  or  per¬ 
sonnel  resources  (Navy  or  contracted)  must  be  made  available  to 
perform  the  required  reviews  and  testing  as  expeditiously  as 
possible. 


3. 2.1. 3. 4  Facilitating  Selection  and  Field  Use  of  Accredited 

Computers . 

The  Program  Manager's  selection  of  a  listed  computer 
for  installation  aboard  a  ship  logically  follows  the  Policy  Admin¬ 
istrator's  role  in  guiding  computers  to  accreditation. 

The  Program  Manager's  selection  of  a  listed  computer 
necessitates  an  evaluation  of  his  system  requirements  and  the 
available  computers.  The  appropriate  PR  must  first  be  selected 
based  on  an  analysis  of  the  proposed  system's  requirements.  The 
analysis  must  address  both  computational  performance  and  logistics 
characteristics.  Once  the  requirements  and  PR  have  been  matched, 
a  life  cycle  cost  analysis  must  be  performed.  This  analysis  will 
support  an  assessment  of  the  system's  total  cost  in  comparison 
with  other  systems'  costs.  The  Program  Manager's  life  cycle  cost 
analysis  will  employ  the  same  O&M  phase  cost  el jments  as  the  Policy 
Administrator's.  However,  the  cost  computation  will  be  more  attuned 
to  the  Program  Manager's  perspective  with  little  or  no  concern  for 
the  computer's  FSED  costs  and  relying  on  an  evaluation  of  avail¬ 
ability  in  a  system  context  rather  than  an  evaluation  for  the  com¬ 
puter  standing  alone. 
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The  Program  Manager  would  be  concerned  with  minimizing 
his  system's  life  cycle  costs  in  the  selection  of  an  accredited 
computer.  While  his  evaluation  is  performed  from  a  different  per¬ 
spective  than  the  Policy  Administrator's  (one  rather  than  many 
systems) ,  it  should  accomplish  the  same  goal,  minimization  of  Navy 
costs,  by  sub-optimization.  However,  the  Program  Manager's  choice 
should  take  into  consideration  total  system  costs  (including  ship 
costs  influenced  by  the  system)  that  contribute  to  the  Navy’s  total 
costs . 

If,  as  time  goes  by,  a  particular  computer  is  not 
selected  because  its  life  cycle  costs  are  higher  than  others  in  its 
PR,  the  vendor  may  be  encouraged  to  reduce  the  computer's  purchase 
price  to  make  it  more  competitive. 

After  a  Program  Manager  selects  an  accredited  computer, 
it  must  be  installed  aboard  a  ship.  Therefore,  an  installation 
schedule  must  be  established  in  accordance  with  dates  of  avail¬ 
ability  of  the  ship.  The  relative  unavailability  of  a  ship  for 
installation  can  be  a  delaying  factor  in  getting  an  operational 
capability  introduced.  There  is  little  that  the  Accreditation 
Policy  can  do  to  improve  ship  availability.  However,  because 
accessibility  of  listed  computers  would  be  dependent  only  on  the 
production  process,  there  should  be  a  smaller  chance  that  a  period 
of  ship  availability  will  be  missed  due  to  the  unavailability  of 
the  computer. 

When  the  computer  is  installed  aboard  ship,  the  logis¬ 
tics  support  capability  must  be  actuated:  trained  technicians, 
supporting  documentation  and  spare  parts  inventory  must  be  avail¬ 
able.  The  quantity  of  spares  stocked  can  be  affected  by  the 
expected  new  technology  of  accredited  computers.  If  the  replace¬ 
ment  price  of  an  LRU  is  lower  than  its  repair  cost,  then  more 
spares  will  be  required.  This  situation  must  be  monitored 


49 


since  (1)  the  high  incremental  cost  of  militarization  will 
for  some  time  keep  parts  costs  high  despite  technology  related 
cost  reductions  and  (2)  the  cost  of  labor  intensive  maintenance 
is  certain  to  rise  considerably.  However,  the  anticipated  tech¬ 
nology  related  improvements  in  reliability  should  reduce  the 
overall  quantity  of  spares  required. 

As  the  number  of  different  computers  (different  vendors 
for  the  same  or  different  PRs)  in  use  on  a  ship  goes  up,  the 
maintenance  problem  is  complicated;  technicians  must  be  trained 
to  maintain  different  computers,  and  logistics  support  mechanisms 
must  be  expanded. 

While  the  increase  in  logistics  support  costs  for  each 
additional  type  of  computer  is  less  than  linear,  the  training  situa¬ 
tion  presents  a  more  serious  problem.  The  training  necessary  for 
each  computer  can  be  costed  by  means  of  a  cost  formula.  However, 
it  is  difficult  to  associate  a  cost  with  the  fact  that  each  tech¬ 
nician  reaches  an  individualized  saturation  point  beyond  which 
further  training  cannot  be  effectively  absorbed.  For  example, 
while  two  technicians  working  together  and  supporting  i  and  j 
computers  of  two  different  types  could  reasonably  take  on  an 
additional  number  of  computers  of  the  same  types,  it  is  less 
likely  that  they  could  handle  k  computers  of  a  third  type. 

If  the  cost  of  adding  a  new  vendor's  computer  is  incor¬ 
porated  into  the  Program  Manager's  life  cycle  cost  formula,  there 
could  be  a  serious  bias  against  the  use  of  computers  that  are 
suited  to  provide  militarily  effective  capabilities.  Maintenance 
technology  can  be  used  to  reduce  the  severity  of  this  situation: 
the  use  of  diagnostic  aids  can  increase  the  number  of  computers 
that  a  technician  can  be  trained  to  support  by  lowering  the  skill 
level  requirements. 
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When  a  decision  is  made  to  purchase  a  listed  computer, 
the  vendor's  ability  to  supply  the  computer  on  the  required 
schedule  (and  at  reasonable  cost)  must  be  considered.  The  vendor 
may  be  unable  to  meet  the  schedules  because  of  either  inadequate 
or  inoperative  production  facilities.  The  relative  unpredict¬ 
ability  of  the  Navy's  demand  under  the  policy  concept  may,  in 
fact,  contribute  to  the  problem.  However,  the  purchaser  would 
still  have  several  alternatives:  (a)  the  original  vendor  could 
adjust  the  status  of  his  production  facilities  to  meet  the  Navy's 
purchase  requirements,  (b)  another  vendor  could  be  given  a  licens¬ 
ing  agreement  to  produce  the  computers,  or  (c)  another  of  the 
listed  computers  could  be  selected  instead.  (The  existence  of 
alternative  purchase  options  should  minimize  the  negative  impact 
on  purchase  options  if  a  computer's  production  is  discontinued, 
for  whatever  reason.)  The  Program  Manager's  life  cycle  cost 
analysis  would,  of  course,  have  to  take  into  account  any  additional 
costs  resulting  from  either  of  these  actions. 

3 . 2 . 1 . 4  Standard  ISAs. 

The  standardization  on  the  ISA  level  will  require  that 
existing  ISAs  for  the  standard  Navy  computers  (UYK-20,  UYK-7) ,  as 
well  as  any  new  standard  ISAs,  be  supported.  It  is  assumed  that 
all  standard  ISAs  will  have  to  be  implemented  on  each  listed 
computer,  probably  by  means  of  either  emulation  or  different  ver¬ 
sions  of  the  computer's  logic. 

3. 2. 1.4.1  Verification  of  ISA  Implementation. 

The  use  of  standard  ISAs  will  require  that  the  Navy 
confirm  the  veracity  of  each  implementation.  The  implementation 
must  be  faithful  to  the  ISA  specifications  and  without  implementa¬ 
tion  related  side  effects.  To  improve  the  likelihood  of  successful 

implementations  by  vendors,  a  clear  definition  of  the  ISA  must  be 
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provided,  perhaps  by  means  of  the  ISP  notation 


A  suitable  method  by  which  to  verify  the  ISA  implementa¬ 
tion  would  be  the  use  of  benchmark  applications  which,  at  minimum, 
straightforwardly  exercise  all  elements  of  the  ISA. 

3. 2. 1.4. 2  ISA  Changes . 

Although  standard  ISAs  will  be  used,  it  is  inevitable 
that  technology  advances  will  argue  for,  or  even  require,  modifica¬ 
tions  to  the  specification  of  the  ISAs.  The  changes  can  result 
from  either  Navy  generated  requirements  or  unsolicited  changes 
advanced  by  vendors.  For  unsolicited  changes,  the  Navy  would 
undoubtedly  evaluate  them  before  giving  them  any  official  sanction. 
If  the  unsolicited  change  were  rejected,  it  would  be  advisable  (in 
the  case  of  a  completely  new  computer)  to  allow  the  vendor  to  submit 
the  computer  for  inclusion  in  the  list  with  the  change  disabled. 
Otherwise,  vendors  would  be  discouraged  from  developing  enhance¬ 
ments  to  the  ISA  if  the  entire  computer  could  be  rejected. 

Changes  approved  or  promulgated  by  the  Navy  would 
become  formal  changes  to  the  ISA  and  be  required  on  all  candidate 
computers  subsequently  submitted  for  accreditation. 

To  ensure  consistency  across  all  listed  computers,  it 
will  not  necessarily  be  purchased  since  existing  users  may  have  no 
changes  to  computers  already  in  use.  The  retrofitted  capability 
will  not  necessarily  be  required  since  existing  users  may  have  no 
use  for  the  change.  If  a  vendor  elected  not  to  implement  the 
field  change  to  be  retrofitted,  the  affected  computer  would  be 
excluded  from  future  purchase  considerations. 

It  would  be  appropriate  for  the  Navy  to  guarantee  reim¬ 
bursement  of  costs  for  the  implementation  of  field  changes.  This 
additional  cost  would  deter  the  policy  administrators  from  approv¬ 
ing  changes  that  were  not  cost-effective.  Also,  this  approach 
would  encourage  vendors  to  implement  the  change  on  existing  com¬ 
puters  to  maintain  consistency  among  the  Navy's  computers. 
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3.2.2  Cost  and  Benefit  Relationships  of  the  Accreditation  Policy. 


Examination  of  the  factors  cited  in  the  proposed  approach 
to  accreditation  reveals,  not  surprisingly,  that  a  cumulative 
price  must  be  paid  to  achieve  the  desired  goals.  In  this  section, 
the  areas  where  costs  are  incurred  and  the  objectives  that  they 
affect  are  presented  diagrammatically . 

In  Figure  3,  the  interrelationship  of  costs  and  benefits 
is  summarized.  Militarization  costs  involve  those  activities 
required  to  meet  the  design  constraints  of  the  policy.  Technology 
costs  reflect  the  cost  of  technological  advances  in  logic  and 
overall  computer  design.  The  costs  associated  with  multiple  FSED 
efforts  by  vendors  (not  always  resulting  in  purchased  computers) 
are  represented  by  development  cost.  Management  costs  for  the 
policy  relate  to  such  activities  as  defining  the  accreditation 
criteria,  communicating  policy  goals  and  procedures,  performing 
proposal  and  accreditation  evaluations,  and  optimizing  procurement 
procedures.  Each  cost  type  yields  a  benefit  in  one  or  more  of  the 
Navy's  goals. 

In  Table  2,  the  positive  and  negative  impacts  of  the  pro¬ 
posed  policy  on  the  respective  goals  of  the  Navy  and  vendors  are 
summarized.  Also,  graphic  representations  are  provided  of  the 
expected  influence  of  the  policy  on  these  goals. 

3.2.3  Review  of  the  Policy  Concept 

Two  basic  premises  were  assumed  in  the  proposed  policy: 

(1)  competition  will  reduce  computer  purchase  price  while  yielding 
improved  performance  for  equivalent  dollars  and  (2)  acquisition 
of  improved  technology  will  result  in  reduced  maintenance  costs. 
Both  premises  may  be  acceptable  on  an  intuative  basis.  However, 
further  validation  of  these  premises  must  be  performed  as  part 
of  the  process  of  initiating  the  Accreditation  Program.  However, 
available  data  and  past  experience  can  be  used  to  preliminarily 
support  these  premises. 
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Figure  3.  Cost-Benefit  Relationships 
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ramif ications  of  competition  for  EDP  equipment  prices  is  readily 

apparent  in  the  decline  of  IBM  mainframe  prices  since  plug  com- 
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patible  machines  (PCMs)  were  introduced  '  .  The  development  of 

functionally  identical  mainframes  that  were  and  are  directly 
price  and  performance  competitive  forced  IBM  to  significantly  cut 
prices.  In  some  cases  the  price  reductions  were  not  the  result 
of  technology  improvements  but  rather  marketing  decisions.  Simi¬ 
larly,  the  favorable  price/performance  ratio  for  small  computers 
is  undoubtedly  the  result  of  a  highly  competitive  market  as  well 
as  technological  progress.  Nonetheless,  the  Navy  and  commercial 
markets  differ  enough  in  character  and  requirements  that  the 
existence  of  competition  for  Navy  business  cannot  be  taken  for 
granted.  However,  if  competition  materializes,  there  is  every 
reason  to  believe  that  price  gains  will  follow. 

Acquisition  of  state-of-the-art-technology  can  be  expected 
to  reduce  maintenance  costs.  The  improved  technology  will  provide 
gains  in  MTBF  and  MTTR  as  well  as  reductions  in  costs  for  spare 
parts.  These  gains  can  be  estimated  by  comparing  Navy  and  com¬ 
mercial  maintenance  costs  as  related  to  hardware  costs.  Data 
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provided  by  Naval  Underwater  Systems  Center  indicates  that  the 
cost  of  consumed  spare  parts  per  year  is  $3, 000-$8 , 000  for  a 
UYK-20.  The  cost  of  a  DS  per  year  per  computer  is  $15, 000-$30, 000. 

If  the  low  end  values  are  totaled  for  a  $55,000  UYK-20,  the  yearly 
maintenance  cost  ($18,000)  is  approximately  one  third  of  the  pur¬ 
chase  price.  For  the  UYK-7,  maintenance  costs  amount  to  a  little 
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less  than  10%  of  the  $275,000  purchase  price.  Industry  experience  , 
however,  indicates  that  maintenance  costs  amount  to  7%  to  15% 
of  hardware  costs.  While  industry  maintenance  costs  are  affected 
by  market  situations  (and  expected  to  rise)  and  militarized  hard¬ 
ware  costs  are  higher  than  those  for  industry,  there  is  a  sub¬ 
stantial  potential  for  savings  by  the  Navy  in  maintenance  costs. 
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SECTION  4.  IMPLEMENTATION  OF  THE  ACCREDITATION  PROGRAM 


In  this  section,  the  recommended  actions  and  responsibilities 
of  the  participants  in  the  Accreditation  Program  proposed  by 
PRC/ISC  are  specified.  These  topics  were  initially  identified 
during  the  analysis  of  the  factors  associated  with  the  proposed 
policy.  A  chronology  of  activities  is  presented  that  extends  from 
the  preparations  for  instituting  the  program  through  the  actual 
policy  procedures  and  the  participants  who  perform  them.  First 
the  responsibilities  of  the  policy  administrator  in  initiating 
the  program  are  discussed.  Then  the  actual  policy  procedures  are 
specified. 

4.1  Preparations  for  the  Accreditation  Program. 

There  is  a  considerable  amount  of  data  collection  and  plan¬ 
ning  that  must  be  performed  before  the  accreditation  of  computers 
can  begin.  The  requisite  actions  are  specified  in  this  section. 
Most  of  these  activities  will  be  performed  in  parallel,  culminat¬ 
ing  in  a  methodology  for  the  Accreditation  Program.  These  activi¬ 
ties  are  summarized  in  Figure  4  which  provides  a  feasible  time¬ 
table  for  the  initiation  and  execution  of  the  Program. 

The  methodology  of  the  Accreditation  Program  must  be  stated 
to  provide  guidance  to  all  of  its  participants  regarding  its  goals 
and  how  they  can  be  achieved.  The  planned  relationship  between 
the  Navy  and  vendors  must  be  stated  and  must  stress  the  importance 
of  the  policy  in  providing  benefits  to  both  the  Navy  and  vendors. 
The  three  essential  elements  of  this  relationship  are  the  expected 
competition  among  vendors,  the  funding  of  computer  development  by 
the  Navy  and  the  treatment  of  accredited  computers  as  commodities 
to  be  purchased  by  Program  Managers. 

The  methodology  should  not  be  formulated  in  a  vacuum,  i.e., 
with  only  the  Navy's  input.  Comments  as  well  as  original  ideas 
should  be  solicited  from  vendors  (perhaps  through  an  attitudes 


Figure  4.  Tentative  Timetable  for  Initiation  of  Accreditation  Policy 


survey)  to  guarantee  a  well  balanced,  complete  and  effective 
methodology.  Conferences  or  panel  discussions  should  be  held 
with  a  wide  spectrum  of  Navy  and  vendor  participants. 

The  Navy  will  have  to  collect  and  evaluate  data  that  is 
pertinent  to  its  goals  as  encompassed  by  the  Accreditation  Policy. 
This  information  will  be  necessary  to  support  the  process  described 
in  the  following  sections  for  defining  the  policy.  The  types  and 
sources  of  the  needed  information  are  outlined  in  Table  3. 

The  collected  data  will  be  essential  to  the  validation  of 
the  Accreditation  Policy  concept,  in  addition  to  providing  a  data 
base  for  policy  details.  The  validation  could  be  performed  either 
in  conjunction  with  a  decision  as  to  whether  or  not  the  program 
should  be  undertaken  or  as  part  of  the  first  call  for  candidates 
for  accreditation.  While  validating  the  concept  prior  to  initia¬ 
ting  the  program  is  the  more  prudent  technique,  it  must  be  recog¬ 
nized  that  any  vendor  supplied  data  carries  no  commitment  and  may 
be  influenced  by  marketing  goals  rather  than  technical  plans. 

4.1.1  Define  Accreditation  Criteria  (Policy  Administrator) . 

The  criteria  used  in  judging  the  suitability  of  a  candidate 
computer  for  addition  to  the  list  of  accredited  computers  must  be 
formulated.  These  criteria  will  define  the  ground  rules  for  vendor 
efforts  and  allow  the  Navy  to  formalize  the  technical  basis  for  its 
computers.  As  proposed,  the  evaluation  criteria  would  encompass 
three  areas: 

•  Design  Constraints  -  These  guidelines  define  charac¬ 
teristics  of  a  computer  which  will  facilitate  its 
effective  use  in  tactical  systems. 

The  formulation  of  performance  bounds  for  PRs  will 
give  some  guidance  for  the  uses  that  the  Navy  envi¬ 
sions  for  its  computers.  The  definition  of  PRs  will 
also  provide  a  set  of  guidelines  for  the  classifica¬ 
tions  for  computers  (see  Section  4.1.3). 


60 


*• 

1  3 

r— >i 

0  P 

>4  0 

P  4) 

P  o 

4H 

3 

•H  P 

•P  3 

4H 

0 

O 

0 

3  3 

rH  td 

0 

p 

03 

a  <v 

o’  a 

■p  p 

i 

•H 

•H  X 

0  e 

XI  3 

0 

p 

14-1  4-1 

P  0 

id  -h 

T) 

•  • 

id 

0 

o 

rH  3 

3 

03 

ft 

Tl  >1 

p 

•P  3 

P 

• 

p 

E 

4-4 

P  T) 

3  3 

P 

id 

3 

0 

0  -H 

0  0 

> 

•H 

0 

o 

P  P 

a  p 

Id  4H 

TJ 

p 

s 

s 

a-P 

0 

3 

0 

0 

4h 

3 

3  3 

Tl 

id 

p 

p 

0 

..  3 

3  O’ 

3  fp 

*H 

•H 

ui  o’ 

0 

3  0 

03 

p 

3 

03 

P 

0  P 

> 

id 

o 

O’ 

■H 

a)  0 

P 

3  0 

rH 

0 

03 

-p  p 

4-4 

P  rH 

3 

3 

P 

id  • 

0 

0 

3 

E 

0 

X  3 

04*0 

•  • 

0  0 

P 

•H 

0 

P 

e  s 

3  3 

E  P 

0 

p 

o 

3  0 

0  3 

P  -H 

0  3 

4H 

id 

id 

P 

0 

o 

3  3 

P  E 

p 

4H 

0  3 

03 

3 

0  E 

•H  -rH 

p 

■H 

p 

Tl  ft 

o 

T3  P 

E  O 

3  P 

03 

Tl 

0 

•h  g 

a 

0  0  • 

0  T> 

O’  3 

o 

0 

p 

>  0 

p 

V  -P  03 

P 

0  0 

o 

P 

3 

o  o 

3 

Tl  3  P 

•H  d) 

P 

O 

•H 

p 

& 

0  a  o 

3  X! 

—  0 

0 

o 

ftT) 

O’p 

p 

rH 

id 

p 

0 

Tl 

e  o  s 

0 

03 

0 

0  • 

O  P 

3 

a;  o  0 

p  p 

3  T3 

>4 

x 

P  3 

P  -H 

id 

> 

o 

0  3 

o 

03 

3  -H 

T) 

T)  Tl 

3 

•h  id 

■iH 

ft  P 

0 

a) 

0  0  O 

0  s 

p 

0 

rH 

E  0 

••  u 

a 

p  -a  p 

■P  0 

O  3 

«4H 

XI 

O  P 

3  O 

>» 

•H  Tl 

p  -p 

<D  rH 

•H 

3 

O  -H 

P  O 

tH 

300 

3  P 

•n  0 

rH 

p 

P 

0  3 

CTO  X 

O  -P 

0  > 

3 

rH  O 

P 

0) 

■P  s 

p  0 

p 

0 

3 

3  P 

p 

P  <D  3 

rH  *H 

ftp  • 

0 

3  3 

ft  0 

<0 

rH 

ftp  • 

>1 

4h 

0 

0  0 

E  p 

a 

«P  P  -H 

ft  0  3 

p  o>  tn 

p 

■H  *H 

O 

0  0  3 

3  Tl  ft 

0  3  0 

p 

p  p 

O  3 

P  > 

ft 

3  -P  P 

3 

0  3 

0 

>i  3 

•H  T) 

3  P  0 

ft 

•  • 

3  P 

T)  P 

P  3 

3  C  >4 

OM-IS 

3 

3 

3  -P 

0  3 

■H  P  P 

O  3  X 

3  3  X! 

•H 

0 

P  t3 

D  E 

p  3  0 

•H 

P  P  o 

0 

tn  *h 

c  0  m 

P  3  T3 

0  3  0 

3 

p 

Tl  P 

<  p 

3  6  P 

O  -P  0 

ft  P 

3 

3 

3  O 

03 

3  0  3 

3  3  P 

0 

U 

3  U 

p  0 

cpp  e 

P  >4  3 

0  3  P 

♦H 

3 

o 

rH  0 

O  -P  0 

•  • 

4H 

rH 

p  p 

Tl  3  <H 

>0  3  3 

3  6 

3  • 

•rH 

3  X 

o 

o)  o’  3 

0  3  0 

3  fit 

P  3 

o 

O  03 

3  -O 

P  0  -rl 

P  3  P 

3  0  0 

3  0 

0 

•H  ’H 

P  3 

O  P  P 

O  ft 

0  P  p 

0  03 

ft 

M  rH 

3  0 

0  C 

0  3  0 

P  0  -P 

O  >4 

3 

P  X 

t}  > 

•n  >i  0 

•n  P  p 

3-0  3 

rH 

O  3 

O  >  P 

0  3 

•P  O’ 

X  3 

< 

0  p 

53  P 

P  3  0 

P  0  3 

3  0  0 

p8  G 

tn 

H  3 

HI  0 

o <  z  ft 

ft  E  3 

S  P  P 

O  3 

H 

H  0 

ft  p 

• 

• 

• 

• 

• 

• 

• 

0 

0 

p 

3 

0 

z 

w 

3 

Z 

3 

P 

3 

a 

-  61  - 


Impact  of  diagnostic  aids:  to  assess  influence  on  required  skill 
levels  and  MTTR  to  validate  compatibility  of  proposed  new  mainte¬ 
nance  tasking  and  diagnostic  technology. 


Compliance  with  the  standard  ISA(s)  will  facilitate 
software  portability  between  systems  in  addition  to 
defining  a  set  of  baseline  characteristics  against 
which  computers  can  be  assessed.  (If  the  computer 
cannot  accurately  execute  the  standard  ISA,  it  will 
not  be  accredited.)  Definition  of  the  ISA  is  dis¬ 
cussed  in  Section  4.1.4. 

The  electronic  interfaces  for  computers  are  other  design 
constraints  which  impact  the  Navy's  use  of  the  embedded 
computers.  Implementation  of  standard  interfaces  (such 
as  NTDS,  RS232  and  188C)  will  facilitate  the  use  of  a 
computer  with  other  systems  and  devices. 

The  specification  of  functional  standards  for  front 
panels  and  the  man/machine  interface  will  make  it 
easier  for  operations  and  maintenance  personnel  to 
read  and  understand  the  state  of  the  computer  at  any 
point  in  time. 

•  Environmental  Standards  -  Environmental  standards 
will  provide  a  basis  for  determining  the  ability  of 
a  candidate  computer  to  operate  under  the  environ¬ 
mental  stresses  imposed  on  embedded  computers.  The 
planned  uses  of  the  computers  should  guide  the  speci¬ 
fication  of  applicable  MIL-SPECs  and  MIL-STDs  as  accred¬ 
itation  criteria.  This  will  necessitate  a  critical 
evaluation  of  the  utility  and  cost-effectiveness  of 
existing  standards  based  on  an  analysis  of  historical 
data  on  reliability,  experienced  environmental  condi¬ 
tions  and  resulting  costs. 

•  Life  Cycle  Costs  -  A  candidate  computer's  life  cycle 
costs  will  be  used  to  estimate  the  total  cost  of  the 
computer  to  the  Navy.  Life  cycle  cost  formulas  will 
be  used  which  incorporate  all  of  the  cost  elements 


associated  with  the  life  cycle  of  a  computer.  The 
computed  life  cycle  costs  will  be  compared  with 
those  of  listed  computers  to  support  an  evaluation 
of  the  candidate's  cost-effectiveness  and  return  on 
investment  as  represented  by  reduced  life  cycle  costs. 

4.1.2  Estimate  Planned  Computer  Purchases  (Policy  Administrator) . 

Several  aspects  of  the  policy  require  that  the  Navy  analyze 
its  projected  computer  requirements  to  establish  an  estimate  of 
the  number  and  type  of  computers  that  will  be  procured  over  time. 
This  information  will  allow  the  Navy  to  gain  a  better  perspective 
on  its  anticipated  requirements  and  costs  while  providing  input  to 
trade-off  analyses.  The  procurement  projections  will  also  be  use¬ 
ful  to  vendors  in  their  efforts  to  gauge  their  costs  and  produc¬ 
tion  requirements. 

These  projections  can  best  be  ascertained  by  canvassing 
Program  Managers  and  planning  agencies  cognizant  of  system  imple¬ 
mentation  plans  the  budgetary  considerations .  Periodic  reviews 
of  the  projections  should  be  performed  to  provide  timely  input  to 
procurement  plans  and  the  trade-off  analyses  by  both  the  Navy  and 
vendors . 

4.1.3  Define  Performance  Ranges  (Policy  Administrator) . 

PRs  play  an  essential  role  in  categorizing  the  Navy's 
computational  requirements  in  addition  to  providing  a  basis  for 
comparison  of  computers.  Accordingly,  each  PR  will  define  a 
bounded  range  of  computational  performance  as  defined  by  three 
computational  performance  parameters:  thousands  of  operations 
per  second  (KOPS) ,  composite  data  transfer  rate  over  external 
I/O  interfaces  and  interrupt  response  time.  Each  of  eight 
distinct  PRs  will  be  defined  by  the  three  parameters,  each 
having  a  medium  or  high  level  of  performance  for  each  PR. 
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The  minimum  value  for  the  levels  of  each  parameter 
will  have  to  be  defined  on  the  basis  of  requirements  for  per¬ 
formance  specified  for  planned  systems.  Current  and  expected 
technology  will  have  to  be  assessed  to  determine  the  feasibility 
of  the  requirements. 

Then  the  planned  systems  should  be  mapped  onto  the 
PRs  to  determine  if  the  mapping  argues  for  fewer  or  more  PRs. 

More  PRs  can  be  established  by  refining  the  medium  and  high 
levels  into  additional  levels.  Similarly,  PRs  can  be  consoli¬ 
dated  by  providing  for  a  single  level  of  performance  for  a 
particular  parameter. 

The  specification  of  PRs  categorizes  the  Navy's  com¬ 
puters  and,  in  turn,  establishes  the  prospective  market  size 
for  each  PR.  Because  market  size  will  be  a  factor  influencing 
the  degree  of  vendor  participation  in  the  policy,  the  defini¬ 
tion  of  PRs  must  also  take  into  account  the  effect  on  the  poten¬ 
tial  market  size  for  vendors. 

4.1.4  Define  ISA  (Policy  Administrator) . 

A  dictated  constraint  of  the  Accreditation  Policy  study 
was  that  a  standard  ISA  would  be  executed  on  all  accredited  com¬ 
puters.  The  definition  of  the  ISA  would  serve  as  a  specification 
of  one  component  of  the  design  constraints.  Whether  an  existing 
(i.e.,  UYK-20  or  UYK-7)  and/or  new  ISA  were  used,  it  would  have 
to  be  defined  concisely  and  precisely  to  facilitate  accurate 
implementation  and  verification.  Specification  of  the  ISA  using 
an  effective  and  widely  accepted  notation  such  as  ISP  would  be  a 
means  to  this  end. 
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The  characteristics  of  the  ISA  would  have  to  be  defined 
in  conjunction  with  an  evaluation  of  desired  and  required  capa¬ 
bilities  as  well  as  the  current  state  of  technology.  The  ISA 
would  have  to  be  functionally  complete  and  responsive  to  the 
requirements  of  the  Navy's  applications. 

A  configuration  management  board  would  be  required  to 
provide  ongoing  expertise  in  the  ISA.  The  board  would  respond 
to  vendor  questions  about  the  ISA  and  handle  Navy  or  vendor 
initiated  Engineering  Change  Proposals  (ECPs)  for  the  ISA. 

4.1.5  Identify  Critical  Design  Issues  (Policy  Administrator) . 

In  Section  3.2.2,  trade-offs  involved  in  the  specifica¬ 
tion  of  both  the  policy  methodology  and  cost  formulas  were  out¬ 
lined  in  the  discussion  of  factors  affecting  Navy  and  vendor 
goals.  While  most  of  these  issues  are  of  obvious  interest  to 
the  Navy,  the  policy  should  not  attempt  to  establish  explicit 
or  rigid  requirements  (in  the  form  of  accreditation  criteria) 
that  vendors  must  meet.  Instead,  the  Navy  should  communicate  to 
vendors  its  perception  of  the  issues  and  the  level  of  attention 
that  should  be  given  those  issues.  It  must  be  expected  that  the 
vendors  will  then  utilize  that  guidance  to  meet  the  Navy's  goals 
and  thereby  enhance  their  competitive  position. 

Some  of  the  trade-offs  involve  the  attitudes  of  vendors 
more  so  than  Navy  concerns.  Therefore,  the  Navy  will  have  to 
gain  an  appreciation  for  vendor  attitudes  and  expectations. 
Accordingly,  the  Navy  will  better  understand  the  factors  affect¬ 
ing  vendor  actions. 

The  critical  design  issues  that  must  be  examined  are 
listed  below: 

•  What  is  the  relationship  between  expenditures  for 
improved  technology  (MTBF,  MTTR,  card  level,  LRU,  and 
diagnostic  aids)  and  maintenance  costs  (labor,  parts 
and  training) ? 
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•  How  will  competition  among  vendors  influence  FSED 
costs  and  computer  purchase  price? 

•  How  will  projected  market  size  and  FSED  phase  profits 
impact  vendors'  inclination  to  participate  in  the 
Accreditation  Program? 

•  What  influence  will  constraints  of  the  Navy  environ¬ 
ment  (technological  and  procedural)  have  on  the  tend¬ 
ency  of  a  vendor  to  participate  in  the  Accreditation 
Program? 

This  report  has  provided  speculative  answers  to  these 
questions.  Nonetheless,  these  issues  must  be  kept  in  the  fore¬ 
front  of  the  program  to  ensure  that  they  receive  the  visibility 
that  is  warranted  by  their  importance. 

4.1.6  Derive  Life  Cycle  Cost  Formulas  (Policy  Administrator) . 

The  computation  of  life  cycle  costs  entails  the  use  of 
cost  formulas  that  incorporate  expected  costs  to  the  Navy.  The 
cost  formulas  provide  visibility  for  costs  that  are  not  clearly 
or  explicitly  billed  to  the  Navy.  The  formulas  are  also  important 
in  highlighting  costs  that  the  Navy  considers  critical  and  that 
should  be  considered  by  vendors  when  making  cost/ performance 
trade-offs  in  their  design.  The  cost  formulas  can  be  used  to 
implement  or  enforce  trade-offs  by  establishing  bounds  for  partic¬ 
ular  cost  elements.  Thus,  if  trade-off  analyses  indicate  that  a 
specific  range  of  costs  for  an  element  must  be  achieved  to  balance 
costs  and  performance,  this  fact  can  be  clearly  stated  in  the 
specification  of  the  cost  formulas. 

The  life  cycle  cost  formulas  will  be  used  in  the  evalua¬ 
tion  of  a  vendor  proposal  for  a  candidate  computer,  in  the 
accreditation  evaluation  for  a  completed  computer,  and  in  deter¬ 
mining  the  cost-effectiveness  of  a  computer  in  a  particular  sys- 


66 


tern  or  application.  In  each  of  these  instances,  the  intent  of 
the  formula  is  the  same — to  define  costs  for  evaluation;  yet  the 
specification  of  costs  in  each  instance  may  vary  as  more  exact 
cost  data  is  obtained. 

Derivation  of  cost  formulas  can  be  accomplished  only 
through  exhaustive  listing  of  the  costs  involved  in  each  phase 
of  the  computer's  life  cycle  followed  by  a  thorough  specification 
of  the  cost  items  in  each  cost  element. 

Cost  formulas  must,  of  course,  undergo  periodic  review 
to  ensure  that  changes  in  costs  are  accounted  for  and  that  trade¬ 
off  decisions  remain  valid. 

4.1.7  Set  up  Facilities  for  Accreditation  Testing  (Policy 

Administrator) . 

Facilities  and  resources  must  be  established  to  perform 
accreditation  evaluations  for  candidate  computers. 

An  essential  tool  in  the  accreditation  testing  will  be 
benchmarks.  Benchmarks  for  computational  performance  will  support 
determination  of  the  applicable  PR  against  which  the  candidate 
computer  should  be  compared.  Benchmarks  will  also  be  required  to 
verify  compliance  with  the  standard  ISA  by  thoroughly  exercising 
all  aspects  of  the  ISA.  Benchmarks  would  also  be  used  to  drive 
the  computer  so  that  its  compliance  with  the  interface  require¬ 
ments  could  be  tested.  The  benchmark  testing  could  be  performance 
at  vendor  facilities  under  Navy  supervision  with  government  fur¬ 
nished  equipment  (GFE)  to  alleviate  problems  in  scheduling  tests. 

Facilities  would  be  required  to  test  compliance  with 
environmental  standards.  Existing  test  facilities  could  be  used 
to  support  accreditation  testing  or  similar  facilities  could  be 
established. 
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4.1.8  Review  Existing  Procurement  Procedures  (Policy  Administrator) . 

The  performance  of  some  ASU  testing  as  part  of  the  accred¬ 
itation  evaluation  is  warranted  by  the  two  ways  in  which  a  com¬ 
puter  must  be  viewed:  as  a  device  standing  alone  and  as  a  com¬ 
ponent  in  an  operational  system.  ASU  procedures  treat  the  com¬ 
puter  completely  within  the  context  of  an  operational  capability. 

The  Accreditation  Policy  will  divorce  the  computer  from  any  system 
or  operational  context,  yet  subsume  some  of  the  testing  and  evalua¬ 
tion  currently  performed  as  part  of  ASU.  There  are  several  activi¬ 
ties  associated  with  the  ILSP  that  can  be  performed  in  the  accred¬ 
itation  evaluation:  (1)  analysis  of  the  materials  related  to  task¬ 
ing,  skill  levels  and  training  for  the  three  levels  of  maintenance, 
(2)  limited  performance  of  PM  and  corrective  maintenance  for  the 
derivation  of  experienced  MTBF  and  MTTR  values,  (3)  assessment  of 
the  spare  parts  plan,  and  (4)  evaluation  of  MRCs  and  technical 
manuals.  This  evaluation  will  require  that  expertise  extant  in 
OPTEVFOR  be  utilized  during  the  accreditation  evaluation. 

In  general,  a  similar  overall  review  of  procurement  poli¬ 
cies  and  practices  must  be  performed  to  (a)  evaluate  their  rela¬ 
tionship  to  the  Accreditation  Policy  methodology,  and  (b)  determine 
if  the  goals  of  the  procurement  policies  can  be  accomplished  better 
or  for  lower  costs  as  part  of  the  Accreditation  Policy. 

4.1.9  Realign  Maintenance  Testing  (Policy  Administrator) . 

The  division  of  maintenance  into  lower  and  upper  echelon 
tasks  is  an  essential  element  in  the  long-term  viability  of  the 
proposed  Accreditation  Policy.  Initially,  the  current  maintenance 
workload  should  be  categorized  into  lower  and  upper  echelon  tasks 
to  assess  the  potential  benefits  of  system  diagnostics  for  each. 

As  diagnostic  tools  (in  concert  with  modular  card  level 
hardware  design)  become  available  that  can  reduce  the  level  of 
expertise  needed  to  perform  lower  echelon  maintenance,  personnal 


grades  and  training  requirements  should  be  better  matched  to 
the  requirements  of  lower  echelon  tasks.  This  matchup  can  be 
exploited  when  the  cost  of  the  training  for  lower  echelon  mainte¬ 
nance  is  outweighed  by  the  lower  costs  resulting  from  the  reduc¬ 
tion  of  the  workload  for  personnel  currently  performing  all  types 
of  maintenance.  These  trade-off  decisions  must  be  made  on  the 
basis  of  data  gathered  on  the  effectiveness  of  the  diagnostic 
tools,  the  training  requirements  for  lower  and  upper  echelon 
tasks  and  the  costs  of  maintenance  labor. 

4.1.10  Define  and  Publicize  Navy  Goals  (Policy  Administrator) . 

The  Accreditation  Policy  has  the  goal  of  helping  the  Navy 
to  obtain  cost-effective  systems  that  provide  required,  militarily 
effective  capabilities.  The  statement  of  this  goal  in  more 
detailed  terms  will  be  required  to  educate  the  participants  in 
the  policy.  Such  a  statement  must  encompass  rationale  for  poli¬ 
cies,  procedures  and  standards  as  well  as  specification  of  tech¬ 
nological  and  capability  objectives.  The  documentation  of  these 
issues  will  improve  the  Navy's  understanding  of  its  own  direction. 

All  aspects  of  the  Accreditation  Policy  should  be  communica¬ 
ted  in  publicized  regional  conferences  and  national  publications 
to  ensure  the  widest  possible  dissemination  of  this  vital  informa¬ 
tion. 

4 . 2  Accreditation  Program  Procedures. 

Procedures  involved  in  the  establishment  of  a  list  of  accred¬ 
ited  computers  and  the  use  of  those  computers  are  discussed  below. 
The  policy  procedures  are  summarized  in  Table  4.  The  respective 
responsibilities  of  the  Policy  Administrator  and  the  Program 
Manager  are  depicted  graphically  in  Figure  5. 
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Table  4.  Policy  Procedures 


Policy 

Administrator 


•  Call  for  candidates 
for  accreditation 


•  Evaluate  proposal 
and  approve  or 
reject  develop¬ 
ment  effort 


•  Monitor  development 
with  critical 
reviews 


•  Perform  accredita¬ 

tion  evaluation 

•  Accredit  or  reject 

computer 


Vendor 


•  Present  proposal  for 
FSED  of  a  candidate 
for  accreditation 


•  Develop  computer  and 
materials  for 
accreditation 
evaluation 


•  Submit  computer  for 
evaluation 


•  Produce  computers  for 
shipboard  use 


Program  Manager 


•  Evaluate  accredited 

computer  based  on 
requirements  and 
life  cycle  costs 

•  Select  an  accredited 

computer  for  use 
in  tactical  system 


•  Purchase  selected 

computer 

•  Establish  logistics 

capability  for 
computer 

•  Develop  tactical 

system 

•  Have  tactical 

system  approved 
for  service  use 

•  Install  computer 

for  operational 
use 


4.2.1  Call  for  Candidates  for  Accreditation  (Policy  Administrator) . 


Once  the  requirements ,  procedures  and  methodology  of  the 
Accreditation  Policy  have  been  established,  a  call  for  candidate 
computers  for  accreditation  would  be  made.  The  call  for  candidates 
should  be  widely  publicized  to  increase  the  response  from  vendors. 
The  call  for  candidates  would,  in  effect,  be  an  RFP  directed  to 
the  entire  computer  industry. 

On  the  initial  call  for  candidates,  special  waivers  or 
allowances  might  be  necessary  to  overcome  inertia  and  get  the 
Accreditation  Program  underway.  The  RFP  would  be  reissued  on  a 
periodic  basis  to  encourage  first  time  or  ongoing  participation 
by  vendors.  Existing  standard  Navy  computers  would  be  effectively 
guaranteed  accreditation  since  they  already  meet  the  overwhelming 
majority  of  the  proposed  accreditation  criteria  and  would  provide 
a  basis  for  comparison. 

4.2.2  Present  Proposal  for  FSED  for  a  Candidate  Computer 

(Policy  Administrator) , 

Vendors  would  then  submit  a  proposal  for  the  development 
of  a  candidate  computer  for  accreditation  in  a  particular  PR. 

The  proposal  should  be  responsive  in  providing  the  vendor's  cre¬ 
dentials,  technology  base  and  plans  for  meeting  the  accreditation 
criteria.  The  implementation  plans  would,  by  implication,  convey 
the  vendor's  understanding  of  the  policy,  the  accreditation 
criteria  and  the  Navy's  requirements.  The  timetable,  resource 
requirements  and  costs  of  the  development  effort  would  be  speci¬ 
fied  in  the  proposal. 

4.2.3  Evaluate  Proposal  and  Approve  or  Reject  Development  Effort 

j  (Policy  Administrator)  . 

The  Policy  Administrator  would  evaluate  the  vendor's  pro- 
|  posal  from  four  perspectives;  technical  feasibility,  potential 

for  technological  and  cost  improvements  to  Navy  computers,  likeli- 
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hood  of  successful  completion  within  cost  and  likelihood  of 
accreditation.  The  evaluation  of  these  points  would  determine 
whether  or  not  the  development  effort  would  be  approved. 


Suitable  Navy  resources  would  have  to  be  available  to 
make  the  necessary  judgments  in  evaluating  the  proposals.  The 
number  of  proposals  that  could  be  approved  for  funding  would 
depend  on  the  available  budget  for  FSED  activities.  Initially, 
funding  should  be  geared  towards  getting  at  least  two  computers 
into  each  PR. 

4.2.4  Develop  Computer  and  Materials  for  Accreditation 

Evaluation  (Vendor) . 

If  a  vendor's  proposal  were  accepted  and  approval  given 
for  the  development  of  a  candidate  computer,  the  computer  itself 
and  supporting  documentation  would  be  produced.  The  following 
documentation  would  be  required  of  the  vendor: 

•  Design  documentation  for  the  computer 

•  Technical  manuals 

•  Operator  and  maintenance  procedures  documents 

•  ILSP 

In  addition,  more  exact  performance  and  cost  data  than  that 
provided  in  the  proposal  would  have  to  be  specified  for  use  in 
the  life  cycle  cost  analysis. 

A  set  number  of  prototype  units  (three  or  four)  would  be 
produced  to  satisfy  requirements  for  different  types  of  accred¬ 
itation  testing,  possibly  at  different  locations. 
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4.2.5  Monitor  Development  with  Critical  Reviews  (Policy 

Administrator) . 

The  Navy  would  monitor  the  vendor's  progress  by  perform¬ 
ing  scheduled  critical  reviews  of  technical  and  cost  status. 

The  cost  reviews  would  guard  against  the  incorrect  application 
of  funds  or  overruns.  The  technical  reviews  would  permit  an 
ongoing  assessment  of  the  chances  for  successful  completion  and 
accreditation.  The  critical  reviews  would  provide  the  Navy  with 
the  opportunity  to  terminate  or  redirect  development  when  justi¬ 
fied  by  the  status  of  the  effort. 

4.2.6  Submit  Computer  for  Evaluation  (Vendor) . 

Once  the  vendor  had  completed  the  development  effort, 
the  computer  would  be  submitted  to  the  policy  administrator  for 
an  accreditation  evaluation.  The  timetable  for  the  evaluation 
would  have  been  agreed  upon  as  part  of  the  proposal. 

4.2.7  Perform  Accreditation  Evaluation  (Policy  Administrator) . 

Once  a  computer  has  been  submitted,  it  would  be  evaluated 
according  to  the  accreditation  criteria:  design  constraints, 
environmental  standards  and  life  cycle  costs.  The  computer's 
compliance  with  the  design  constraints  would  be  tested  with 
benchmark  and  operational  tests.  Satisfaction  of  environmental 
standards  would  be  tested  in  accordance  with  applicable  MIL-STDS. 

The  computer's  life  cycle  costs  would  be  computed  using 
the  policy's  life  cycle  cost  formulas.  The  computed  costs  would 
be  in  current  dollars  (to  account  for  inflation,  etc.)  and  com¬ 
pared  to  the  costs  of  already  listed  computers  in  the  appro¬ 
priate  PR.  The  cutoff  cost  would  be  the  value  that  a  candidate 
would  have  to  better  to  be  listed. 
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4.2.8  Accredit  or  Reject  Computer  (Policy  Administrators) . 


The  results  of  the  accreditation  evaluation  would  be  used 
to  support  a  decision  to  accredit  or  reject  a  candidate  computer. 
If  the  computer  received  accreditation  it  would  be  added  to  a 
published  list  of  accredited  computers.  Program  Managers  with  a 
computer  requirement  would  consult  the  list  for  current  offer¬ 
ings.  If  the  computer  were  rejected  it  would  not  be  listed,  but 
could  be  resubmitted  following  resolution  of  any  deficiencies. 

4.2.9  Evaluate  Accredited  Computers  on  the  Basis  of  System 

Requirements  and  Life  Cycle  Costs  (Program  Manager) . 

A  Program  Manager  with  plans  to  develop  an  application  or 
system  using  an  embedded  computer  would  consider  only  those  com¬ 
puters  on  the  accredited  list.  The  Program  Manager  would  first 
assess  his  computational  performance  requirements  to  determine 
the  most  suitable  PR  from  which  to  choose .  The  vendors  for  the 
computers  in  the  PR  would  be  contacted  to  verify  that  the  com¬ 
puter  could  be  provided  as  required.  If  the  vendor  were  unable 
to  supply  the  computer  as  needed,  that  computer  would  be  excluded 
from  further  consideration  in  the  program  manager's  selection 
process. 

The  computers  within  the  selected  PR  would  be  evaluated 
in  two  ways:  (1)  their  ability  to  satisfy  the  Program  Manager’s 
requirement  as  represented  by  performance  characteristics  (includ¬ 
ing  MTBF,  MTTR,  Size,  etc.)  and  (2)  the  life  cycle  costs  of  the 
planned  system  with  each  of  the  listed  computers.  The  computer 
deemed  best  (i.e.,  with  lowest  total  life  cycle  costs)  on  the 
basis  of  this  evaluation  would  be  selected. 
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4.2.10  Purchase  Listed  Computer  (Program  Manager) . 


Following  the  comparison  of  his  requirements  with  the 
capabilities  of  accredited  computers  in  the  appropriate  PR,  the 
Program  Manager  would  initiate  procurement  of  the  selected  com¬ 
puter  in  a  quantity  and  to  a  schedule  suited  for  his  program. 

The  procurement  decision  would  be  communicated  to  the  Policy 
Administrator  to  ensure  that  any  available  information  about  the 
vendor  or  computer  was  taken  into  consideration.  The  Policy 
Administrator  would  also  use  this  feedback  to  fine  tune  the 
methodology,  procedures  and  data  used  throughout  the  policy. 
However,  the  Policy  Administrator  would  have  no  mandated  influence 
on  purchase  plans. 

4.2.11  Produce  Purchased  Computers  (Vendor) . 

The  vendor  for  a  computer  selected  for  purchase  would 
provide  the  purchaser  with  a  purchase  price  and  a  delivery 
schedule.  (The  inability  of  a  vendor  to  handle  a  "reasonable" 
purchase  could  result  in  the  computer  being  removed  from  the  list.) 

4.2.12  Implement  Logistics  Support  for  Computer  (Program  Manager) . 

The  first  use  of  a  computer  would  require  the  institution 
of  a  logistics  support  capability.  This  would  involve  the  follow¬ 
ing  activities: 

•  Establish  and  stock  an  Inventory  Control  Point  (ICP) . 

•  Establish  parts  list  using  Navy  part  numbers. 

•  Establish  facilities  for  depot  level  maintenance  and 
support . 

•  Institute  training  programs  for  operators  and  mainte¬ 
nance  personnel . 
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4.2.13  Develop  System  with  Accredited  Computer  (Program  Manager) . 

The  delivery  schedule  for  purchased  computers  will  have 
to  include  initial  production  units  available  for  developing 
software  for  the  planned  operational  capability.  (The  functional 
interchangeability  of  accredited  computers  would  allow  the  ear¬ 
liest  stages  of  software  development  to  be  performed  on  more 
readily  available  units  of  another  accredited  computer  if  necessary.) 

4.2.14  Have  System  Approved  for  Service  Use  (Program  Manager) . 

Although  the  viability  of  some  logistics  and  support 
features  of  the  computer  would  be  confirmed  at  the  time  of  the 
accreditation  evaluation,  others  (including  operational  effective¬ 
ness  of  the  system)  would  continue  to  be  verifiable  only  in  the 
course  of  OT&E  for  ASU.  Thus,  it  would  still  be  necessary  for  a 
Program  Manager  to  gain  ASU  for  the  computer  as  part  of  his  opera¬ 
tional  system  (rather  than  for  the  computer  itself) ,  via  a  Test 
and  Evaluation  Plan  instead  of  a  Test  and  Evaluation  Master  Plan. 

4.2.15  Install  Computer  for  Operational  Use  (Program  Manager) . 

The  POA&M  for  the  Program  Manager's  system  would  include 
a  timetable  for  the  shipboard  installation  of  the  system  (and  the 
included  computer)  for  both  OT&E  and  full  scale  shipboard  use. 

The  installation  of  the  computer  would  be  performed  by  either 
Technical  Representatives,  shipyard  personnel  or  the  ship's  own 
force.  The  installation  would  have  to  be  coordinated  with  the 
provision  of  spares  and  the  availability  of  trained  operators  and 
maintenance  personnel  as  well  as  supporting  documentation. 
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SECTION  5.  SUMMARY 


The  Accreditation  Policy  proposed  in  this  report  is  intended 
to  define  a  Navy  management  approach  to  accreditation  that  will 
lead  to  the  acquisition  of  more  cost-effective  embedded  computers. 

Although  the  report  could  have  proposed  a  strategy  that  tied 
Navy  actions  to  a  specific  timetable  for  technological  milestones, 
it  was  deemed  more  useful  to  define  a  comprehensive  framework  for 
dealing  with  vendors  in  order  to  obtain  improved  technology. 

Several  of  the  Navy's  goals  (e.g.,  improved  reliability  and 
maintainability  of  computers)  are  reflected  in  the  commercial 
world.  Therefore,  it  can  be  expected  that  sizeable  gains  will 
accrue  to  the  Navy  if  a  symbiotic  relationship  can  be  established 
(via  the  Accreditation  Policy)  between  the  Navy  and  vendors.  The 
commercial  marketplace  has,  to  date,  controlled  the  pace  and 
direction  of  maturing  technology.  There  is  little  reason  to 
believe  that  the  Navy  can  expect  to  exert  any  significant  influence 
on  technology  trends,  instead,  the  policy  should  allow  the  Navy 
to  ride  the  wave  of  technology. 


REFERENCES 


1.  "Military  Computer  Architectures:  A  Look  at  the  Alternatives,"  special 

issue,  Computer,  Oct.  1977. 

2.  E.  W.  Martin  et.  al.,  "MCF:  The  Military  Computer  Family,  Parts  I -VI," 

Military  Electronics / Countermeasures ,  Mar.  1979-Sept.  1979. 

3.  "Final  Report  of  the  Navy  Embedded  Computer  Review  Panel,"  Oct.  1978. 

4.  secnavinst  5000.1,  System  Acquisition  In  the  Department  of  the 

Navy. 

5.  mil-e-16400,  Military  Specification  Electronic,  Interior  Communication 

and  Navigation  Equipment,  Naval  Ship  and  Shone:  General  Specification 
Eon. 

6.  E.  G.  Cale,  L.  L.  Gremillion  and  J.  Likenney,  "Price/Performance  Patterns 

of  U.S.  Computer  Systems,"  Conn.  ACM,  Apr.  1979,  pp.  225-233. 

7.  B.  H.  Rudwick,  Systems  Analysis  fon  Effective  Planning:  Principles  and 

Cases,  John  Wiley  &  Sons,  Inc.,  1969. 

8.  J.  Durgavich  and  F.  Koester,  "Cost  Benefit  Analysis,"  IEEE  AUTOTESTCON, 

1979,  pp.  212-216. 

9.  G.  A.  Drown,  "A  Cost  Effective  Approach  to  ate,"  IEEE  AUTOTESTCON, 

1979,  pp.  229-233. 

10.  mil-std-1390b.  Level  of  Repain. 

11.  opnavinst  4720.9,  Approval  of  Systems  and  Equipment  fon  Service  Use. 

12.  E.  K.  Yasaki,  "The  High  Cost  to  Maintain,"  Vatamatcon,  Feb.  1979, 

pp.  59-63. 

13.  M.  Phister,  Jr.,  "Analyzing  Computer  Technology  Costs-Part  2:  Maintenance," 

Computer  Design,  Oct.  1978,  pp.  109-118. 

14.  J.  B.  Clary  and  R.  A.  Sacane,"  Self-Testing  Computers,"  Computer, 

Oct.  1979,  pp.  49-59. 

15.  R.  C.  Seven  and  S.  R.  Jenkins,  "Computer,  Heal  Thyself!,"  Mini-Micro 

Systems,  Jul.  1978,  pp.  47-51. 

16.  M.  T.  Ludvigson,  "Built-In  Test  in  MIL-STD-1553  Systems,"  IEEE  AUTOTESTCON, 

1979,  pp.  102-103. 

17.  R.  Lorentzen,  "Troubleshooting  Microprocessors  with  a  Logic  Analyzer 

System,"  Computer  Design,  Mar.  1979,  pp.  160-164. 


-  79 


REFERENCES  (Cont’d) 


18.  G.  A.  Champine,  "What  Makes  a  System  Reliable?,"  Datamation,  Sept.  1978, 

pp.  195-206. 

19.  c.  G.  Bell  and  A.  Newell,  Computer.  S&LUCtu/iz& ’•  R eadingi  and  Examples, 

New  York,  McGraw-Hill,  1971. 

20.  L.  Solomon,  "IBM  Versus  the  PCM's,"  Datamation,  Feb.  1979,  pp.  100-103. 

21.  S.  J.  Ippolito,  "Measure  for  Countermeasure,"  Datamation,  Feb.  1979, 

pp.  120-126. 

22.  Naval  Underwater  Systems  Center  Memorandum,  Ser:  03551-35,  12  Feb.  1980. 

23.  W.  R.  Smith,  J.  J.  Cornyn,  A.  H.  Coleman  and  W.  R.  Svirsky,  "Life  Cycle 

Cost  Models  for  Comparing  Computer  Family  Architectures,"  UationaZ 
Compute a  ConfieA&nce.,  1977. 

24.  M.  Phister,  Jr.,  "Technology  and  Economics:  Relationship  Between 

Diagnostic  Programs  and  MTTR, "  ComputeA  Design,  Jun.  1979,  pp.  44-49. 


80 


END 


DATE 

FILMED 


DTIC 


